Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose real behavior: the z-order-dependent dual effect, the GUID rebinding (first-appearance) machinery, and the confirmation criterion (target becomes the last-reported active window). It omits auth/permission needs and any failure/edge behavior, and the density makes the disclosure hard to extract.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is an unstructured wall of jargon with scattered backticks and parenthetical asides. Only the first sentence is well front-loaded; the rest mixes implementation trivia with the actionable rule, hurting scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values (window_ref, activated, etc.) need not be spelled out. The description covers the core activation semantics adequately, but for a tool with zero schema coverage and no annotations, the missing parameter guidance and permission/edge-case context leave gaps.

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

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 for all four parameters. It adds meaning to window_ref ('default the fixture form's app ref') and capture ('replays the genuine navigation from capture'), but host and port are entirely undocumented and even the two covered params are explained only obliquely.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a clear verb+resource: 'Bring a buried top-level window to the front natively.' It also distinguishes itself from a sibling, explaining that activate and close are the same command and pointing to close_window. The purpose is legible, though it is soon buried under heavy jargon.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explains the contextual behavior (background window activates, active window closes) and cross-references close_window, which is meaningful routing information. However, it gives no clean 'use this when' framing and no prerequisites or exclusions beyond the implicit z-order rule.

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

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 that the append is server-side and persistent, that the row is MARKED (PF_ROW_ADDED_<n> / PF_ADDED_TEXT) and activated, that PF_LAST_ACTION is set, and that the click is capture-free. It also gives verification paths. It omits auth/permission preconditions and failure behavior, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded purpose followed by mechanism, verification, and return shape; every sentence contributes technical substance despite the dense identifier-laden prose. Slightly overstuffed for a single-purpose action, but nothing is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so explaining return values is not required, and the description still adds mechanism and verification context that an agent needs for this non-obvious fixture. The notable gap is the complete absence of parameter guidance for host/port/capture and any statement of permissions or preconditions.

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

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

Schema description coverage is 0% for all three parameters (host, port, capture), and the description never explains what any of them mean or how to set them. The phrase 'capture-free' is ambiguous against the 'capture' parameter and may even confuse. With low coverage the description is expected to compensate, and it does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource ("Add a persistent row to the fixture table natively") and contrasts it with the standard add-row behavior, making it distinguishable from siblings like delete_table_row, copy_table_row, and move_table_row. The concept is specialized and jargon-heavy ('fixture', PF_* markers), but the action is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It explains why this tool exists rather than the standard add-row path ("The standard «add row» discards an uncommitted empty row"), and notes the equivalence to click_command('PF_ADD_ROW'). However, it never states when to choose this over siblings such as set_table_cell, copy_table_row, or click_command directly, so routing remains implied.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose meaningful behavior: the form opens a NEW window, the Pattern field is set and Find clicked, the value is a UTF-16 fixed-width buffer bounded by the captured length, and there is no clean read-back so the list only narrows. It omits any error/permission or failure-mode context, keeping it short of exemplary.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The single dense sentence packs in nested parentheticals and internal jargon ('GUID rebinder rebinding the dialog window (the answer_dialog / open_card machinery)'), making it hard to parse. Some content earns its place (default-field note, verification hint) but the structure is not front-loaded or clean.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex UI-automation tool with an output schema (so return values need not be re-explained), the description covers the flow, side effects and verification adequately. Gaps remain around preconditions and the unexplained host/port/captured_value parameters, but nothing critical for invocation is missing.

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

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

Schema description coverage is 0% across 6 parameters, so the description must compensate. It adds real meaning to value (re-targeted buffer, bounded by captured length), capture (the captured FieldSelector at «Код») and search_command (the default ДенамическийСписокИерархияНайти), but leaves host, port and captured_value unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause states a specific verb and resource: filter a dynamic list via the «Расширенный поиск» dialog. However, the purpose is then buried under implementation jargon (GUID rebinder, answer_dialog/open_card machinery) and it never names its closest siblings (search_list, search_list / choose_from_list) to differentiate itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is only implied: it describes the captured flow and that the search targets the dialog's default field (FieldSelector left at «Код»), plus a verification hint via capture_screenshot. There is no explicit when-to-use vs. the alternative list-search tools nor any stated preconditions (e.g., that the dialog must already be open/captured).

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and largely meets it: it discloses the window-level command mechanism, the GUID rebinder's live rebinding, commit confirmation via result_marker, and the fact that a new top-level window opens. It omits practical prerequisites (a live test client / connection, an existing capture fixture) which leaves a gap for a mutation-style operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first sentence, but the body is a dense run-on of internal jargon (SecondaryFrame GUIDs, raw command bytes, GUID rebinder) that is hard to parse. The information earns its place but the structure sacrifices readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be re-explained, and the description does describe the commit-confirmation flow. But with zero annotation coverage and 0% param documentation, it should specify prerequisites and the fully-understood parameter set; it stops short of that.

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

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. It lends meaning to raise_command, result_marker, and capture ('replays the genuine dialog session from capture'), but host and port are never explained and the semantics of dialog_sf/committed are only implied. It covers the key params partially rather than fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Answer a 1C modal dialog (ПоказатьВопрос / ПоказатьПредупреждение) natively') and explicitly distinguishes itself from the popup choice list sibling that 'reuses the form window'. An agent can identify the tool's role without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It implicitly contrasts the real dialog with a popup choice list and notes the WARNING (ОК) path is the default while the QUESTION (Да/Нет) path uses the same mechanism. However, it never gives an explicit when-to-use-this-vs-that rule or prerequisites, so selection guidance is only implied.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It usefully signals that the query is read-only and that it must return a single row, but says nothing about failure semantics (does a false assertion raise?), the auth implications of the user/password parameters, or timeout behavior for a host-side COM call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the core purpose followed by the usage condition and the input contract. No filler or repetition; every sentence adds information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation, and the core query/op semantics are covered. However, for a 9-parameter tool with zero schema description coverage and no annotations, the absence of any failure-mode or auth/timeout guidance leaves meaningful gaps.

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

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

Schema coverage is 0% across 9 parameters, so the description must compensate and does so partially: it clarifies that `query` must return one row whose first value (or `count_field`) is numeric, that `op` accepts eq/ne/gt/lt/ge/le, and implies `expected`. It leaves infobase_path, user, password, prog_id, and timeout_sec unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (assert) and a precise resource (a numeric result from a read-only host-side COM query), and the condition 'file infobases where OData is not published' contextually separates it from the OData-based assertion siblings. It stops short of naming an alternative sibling explicitly, so it is clear but not maximally differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives an explicit usage condition: reach for this on file infobases where OData is not published, which routes the agent correctly away from OData-based assertions. It offers no explicit when-not or named alternative, so it is clear context without exclusions.

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

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: it discloses read-only OData access, connection sourcing from params or env vars (QA_MCP_ODATA_URL/USER/PASSWORD), the exclusivity-lock failure mode, and the return shape {ok, actual, expected, record_count, deprecated, deprecation}. This is unusually rich disclosure of auth, environment, and failure semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The deprecation caveat is front-loaded and the tool mechanics follow in a logical order; the second DEPRECATION paragraph adds detail rather than pure repetition. It is somewhat long, but nearly every sentence (connection source, return shape, lock behavior) earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a deprecated, 10-parameter, cross-cutting assertion tool, the description covers purpose, usage boundaries, alternatives, connection/auth sourcing, failure mode, and return shape. Even though an output schema exists (so return values need not be spelled out), the definition is complete for correct invocation.

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

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

Schema description coverage is 0% across 10 params, so the description must compensate. It explains the semantically critical ones (entity_set, filter, key, field, expected, match with its enum values) and hints at connection params via 'params or env', but leaves select, base_url, user, and password uncharacterized beyond that hint, so the compensating coverage is strong but incomplete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Assert a value in the DATA LAYER via read-only 1C OData', and names the exact locating mechanism (entity_set plus filter or key) and comparison modes (equals|contains|regex). It also implicitly distinguishes itself from form-level siblings like assert_form_value by scoping to the data layer, and explicitly points to read_record/write_form_fields_by_label as alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives explicit when-to-use ('valid ONLY against a SEPARATELY published, non-exclusive OData endpoint') and when-not (an infobase opened by a test client is exclusively locked, making OData read-back impossible). It names concrete alternative tools for the blocked case (write_form_fields_by_label value-read, read_record, read_form_descriptor), leaving nothing to inference.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses deprecation, the OData read-only nature, the exclusive-lock conflict, and the endpoint precondition, plus the returned fields. It stops short of explaining auth requirements, failure behavior, or what happens when the assertion fails, so it is strong but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the critical deprecation warning before the core purpose, which is the right ordering. It is dense and somewhat repetitive (restating the return shape already covered by the output schema), but every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter QA assertion tool with no annotations and 0% schema coverage, the description supplies purpose, deprecation context, operator semantics, examples, and the endpoint precondition. It is largely complete, with the auth/endpoint parameters being the remaining hole; the output schema already covers return values.

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

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

Schema coverage is 0% across 7 parameters, so the description must compensate. It does explain op (eq|ne|gt|lt|ge|le), expected (via the expected=0 example), filter, and implicitly entity_set, but leaves user, password, and base_url undocumented — a substantial gap at this parameter count.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Assert the NUMBER of records matching a filter in the DATA LAYER' — which is clearly distinct from siblings like assert_form_value or read_record. It also names the sibling to route to under the deprecated path (read_record / read_form_descriptor).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives explicit when-to-use examples ('assert a posting created exactly N register rows', 'no orphan remains'), explicit when-not (deprecated for a test-client-held base under an EXCLUSIVE lock) and the alternative to use instead. It further constrains applicability to 'a separately published, non-exclusive endpoint'.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description carries the full burden. 'ASSERT on live value' hints at pass/fail semantics but says nothing about what happens on mismatch (raise vs return), whether it blocks or polls, timeout behavior, or what mode/groups do. For an assertion tool, failure semantics are exactly what an agent needs and they are absent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with no filler, but its brevity stems from under-specification rather than disciplined editing. It is front-loaded but minimally informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 8 parameters, an output schema, and a rich cluster of assert/wait siblings, yet the description covers neither behavior on failure nor the roles of mode, groups, or capture_dir. An output schema relieves it of explaining return values, but the behavioral gaps remain too large for this complexity.

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

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

Schema description coverage is 0% across 8 parameters (host, port, mode, groups, capture_dir, manager_templates, field, expected). The description adds no parameter meaning beyond the schema, so it does nothing to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (ASSERT) and resource (a form field's live value), which tells an agent this reads current state and fails/passes rather than mutating. It does not distinguish itself from the sibling wait_for_form_value or clarify the assert-vs-wait distinction, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

There is no when-to-use guidance, no prerequisites, and no mention of the closely related wait_for_form_value or the write_form_value family. The agent must infer entirely from the name which of the several assertion/wait siblings applies.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses important behavior beyond schema: it attaches without owning the process, the returned handle status records attached=true and owns_process=false, and the MCP server records the endpoint as the active attached context for replay-backed tools. It still omits auth/error behavior, timeout semantics, and conflict handling for multiple attaches.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short paragraphs, with the core purpose front-loaded in the first sentence and useful context following. There is no filler or repetition, and the agent can parse the key points quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists and the description adds usage context, but with three undocumented parameters and no annotations, the definition leaves gaps around parameter roles, timeout behavior, and failure modes when the endpoint is not listening. It is minimally viable but not complete for an attach operation that changes active MCP context.

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

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

Schema description coverage is 0% for three parameters, so the description should compensate. It does not explain host, port, or connect_timeout_sec; it only alludes to default host/port in the context of replay-backed tools, leaving the actual parameters undocumented. This is well below adequate for a low-coverage schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource—attach to an already-listening /TESTCLIENT endpoint—and immediately distinguishes it from process-owning siblings by saying 'without owning its process.' An agent can select this over launch_test_client/stop_test_client without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives a clear when-to-use condition: clients started out-of-band, such as with a custom environment or host-side launcher. It does not explicitly name the alternative tool (e.g., launch_test_client) or state when not to use this, but the context is strong enough to guide selection.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it discloses the capture mechanism (scrot, ImageMagick fallback), the window-matching fallback with matched_window_id=null, and the return payload shape. It even tells the agent to read the PNG at `path` rather than expecting inline image data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action in the first sentence, then tacks on parameter and return detail. The scrot/ImageMagick implementation note is arguably extra but is useful for debugging failures; overall tight with little waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although an output schema exists (so return fields needn't be described), the description restates them helpfully, and it covers the display source, window matching, fallbacks, and platform. An agent has everything needed to invoke and consume this tool correctly.

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

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

Schema coverage is 0%, so the description must compensate. It fully explains `display` (source and format, e.g. ':101') and `window` (title substring via xdotool, fallback semantics), but `out_path` is never mentioned, leaving one of three parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Capture an OS-level PNG screenshot of the TestClient's X display') with the platform clarified. It is unambiguous and its function is distinct from every sibling tool listed, none of which capture pixels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The intended use (grabbing a visual of the running test client) is implied rather than stated, and there is no explicit when-to-use or when-not-to-use guidance. It does, however, explain the conditional behavior of the window-vs-full-display path, which routes the caller's choice.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full behavioral burden and does well: it discloses the wire-level protocol (choose tag 'e0 4b 53' + length-prefixed value), that no new SecondaryFrame needs binding because the popup reuses the window, and that commit is verified by scanning responses for the ASCII marker Сообщить(...). This is rich context beyond a bare mutation claim.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, which is good, but the single paragraph is dense, backtick-heavy and jargon-laden, interleaving protocol bytes, flow steps and verification logic. It is information-rich yet difficult to parse, so efficiency is only moderate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no elaboration, yet the description still notes the result shape ({captured_value, value, accepted, committed, message}). Combined with the flow, commit-verification mechanism and parameter roles, an agent has enough to invoke it correctly.

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

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 largely does: it explains value (list-item VALUE NAME), base_command (the command that raises the choice list), captured_value/capture (the genuine setup replayed to open the form) and message_prefix (used in the verification marker), plus their interrelations. Only host/port go unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb+resource: 'Pick a value from a ПоказатьВыборИзСписка modal.' It further distinguishes itself from the sibling set_choice by noting it uses the same 'e0 4b 53' family but is addressed at the FORM rather than a radio. The Russian modal name adds jargon but the action is still identifiable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It lays out the required flow (open the form, click base_command, then pick value), which implies when the tool applies. However it never explicitly says when to prefer this over siblings like choose_from_menu or set_choice, nor any precondition/exclusion. Usage is implied rather than stated.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses the wire tag, the re-targeting from captured_value to value, that no new SecondaryFrame is opened, the form replay from capture, the resulting user message, and confirmation on the wire. This is far more than a restatement of schema or name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence, followed by dense technical context. The text is long but most sentences contribute behavioral or parameter meaning, with little obvious filler; the main cost is heavy parenthetical protocol detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, absence of annotations, and an output schema covering return values, the description supplies strong behavioral and mechanistic context. It is slightly incomplete for the lowest-level parameters and usage selection, but it gives enough for an agent to understand the operation and call it correctly.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate. It adds meaning for value, captured_value, base_command, and capture by explaining how they are replayed and re-targeted, but it does not explain host, port, or message_prefix, leaving part of the parameter surface undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: picking an item from a ПоказатьВыборИзМеню popup menu. It explicitly names and distinguishes itself from the sibling choose_from_list by calling the popup its wire twin, so an agent can differentiate them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description references the related alternative choose_from_list and explains the mechanical relationship, but it does not explicitly say when to use this tool versus that sibling or other alternatives. Usage is implied by the popup-menu context rather than stated as a clear condition.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full load and does so well: it discloses that it opens the form, replays the genuine setup from 'capture', sends a re-targeted click, and that a click yields no value read-back so verification must go through a side-effect field or a screenshot. That is meaningful behavioral context for a mutation-style action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the action and stays to two dense sentences with no filler. The parenthetical hex and path references add precision but make it slightly hard to parse on first read.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation action with no annotations, the description covers what happens, what is mutated, how the click is sourced, and how to verify the outcome, plus it names the return shape (aligned with the existing output schema). An agent has enough to call it correctly; only explicit when-to-use routing is absent.

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

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

Schema coverage is 0% across 5 parameters, so the description must compensate. It explains capture (the genuine setup that clicked base_button), base_button, and target_button (defaults to base_button) reasonably, but host and port are left entirely to the schema defaults with no semantics given.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ('Click a form-command BUTTON natively') and names its functional relatives (switch_page, toggle_checkbox), which lets an agent distinguish it from those siblings. It stops short of a crisp one-line purpose because the mechanism detail (the hex command, Group/Button path) crowds the opening.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

By calling itself the 'Button twin of switch_page / toggle_checkbox' it implies the selection rule (use this for command buttons, those for pages/checkboxes), but it never states explicitly when to choose it or when not to. The usage signal is inferable rather than stated.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and largely does: it discloses the replay mechanism, GUID rebinding, truncation just before subsequent closes so only the target window is closed, and verification via the live SecondaryFrame being reported before but gone after, plus the window behind becoming active. This is unusually rich behavioral disclosure. Auth/permission requirements and failure modes are not addressed, keeping it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is well front-loaded, but the remainder is a sprawling run-on dense with internal jargon (SecondaryFrame, GUID rebinder, capture replay, truncated replay) that obscures rather than clarifies. Much of the mechanism detail is not needed to select or invoke the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the inline return-shape listing is redundant but harmless. For a 4-parameter tool with no annotations, the description thoroughly covers behavior but leaves host/port semantics undocumented, so an agent still lacks full parameter context despite the verbose prose.

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

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

Schema description coverage is 0% across 4 parameters, so the description must compensate but only partially does. It clarifies window_ref (defaults to the card's record data ref) and gives context for capture (the captured open-card flow), but host and port receive no explanation and their defaults are buried in the schema. The heavy coverage gap is only partly closed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a clear verb+resource: 'Close a top-level window natively.' It also distinguishes its scope from siblings by contrasting the window-level close against the dialog-level close in answer_dialog, so an agent can separate it from dialog handling. The clarity is undercut by heavy internal jargon, but the core action is identifiable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The NOTE provides real guidance: it explains that the tool replays the captured open-card->close flow and therefore closes that specific card window, and tells the user to capture that flow to close a different window. However, no explicit alternatives or when-not-to-use conditions are named beyond this constraint, leaving the agent to infer the rest.

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

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 it does well: it discloses that the doctor runs against the authenticated host-agent on the Windows host, performs a read-only query when requested, and returns an elevated regsvr32 remediation command when TypeLib is missing. It does not state whether the tool itself mutates state or requires elevated privileges to invoke, leaving a small gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the purpose and followed by scope of checks and remediation behavior. No filler, every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is not needed, and the description covers the host-agent targeting and remediation behavior. The remaining gap is parameter-level detail (credentials, prog_id, timeout) that is undocumented in both schema and description.

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

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

Schema description coverage is 0% for 6 parameters, so the description must compensate, but it only implicitly references infobase_path and query. It says nothing about user/password credentials, prog_id defaulting to V83.COMConnector, or the timeout_sec parameter, leaving half the surface undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Diagnose') and resource ('Windows V83.COMConnector registration') and lists exactly what the doctor checks (registration state, TypeLib presence, COM creation, connection, optional read query). This clearly distinguishes it from siblings like query_com or assert_com_count, which exercise the connector rather than diagnose its registration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The context makes clear this is a pre-flight/health-check tool run against the Windows host, and the optional read smoke is framed as such. However, it doesn't explicitly say when to prefer this over qa_mcp_doctor or query_com, nor when the read smoke should be enabled vs skipped.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and discloses substantial behavior: it replays the PF_COPY_ROW fixture click, is capture-free, inserts a copy below the active row with a _COPY suffix, makes the copy active, and notes the state is session-local. It even describes the expected return object, though it does not discuss permissions or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is front-loaded and useful, but the rest is a dense run-on mixing fixture details, an example, and verification instructions. It is informative but not tightly structured or concise, with parenthetical implementation details that add noise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

It covers the behavioral contract of the copy operation and gives verification guidance, and an output schema exists so return values need not be fully explained. However, it omits all parameter information and, with no annotations, does not fully describe permissions, side effects, or operational constraints.

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

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

The schema has three parameters (host, port, capture) with 0% description coverage, and the tool description never mentions them. The description compensates for none of the missing parameter semantics, leaving host/port/capture entirely undocumented beyond their defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Copy the ACTIVE table row natively,' and explicitly scopes it to the active row. It also distinguishes the operation from sibling tools like select_table_row, though the dense fixture jargon slightly obscures the plain purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives a clear prerequisite: 'Select the target row first with select_table_row.' It also says to verify in the SAME session via assert_form_value, which helps route the agent. However, it does not explicitly contrast when to use this instead of add_table_row or move_table_row.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose key traits: deletion is session-local form state that resets on a fresh form-open, so it must be verified in the same session, and it returns {base_button, target_button, accepted}. It doesn't cover auth/permission requirements or error behavior, but the mutation semantics and state lifetime are unusually well documented.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The action and its mechanism are front-loaded, followed by a worked example, verification guidance, and the return shape. It is dense and peppered with domain-specific fixture/command jargon, but each clause carries real operational information rather than repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a niche form-automation mutation tool, the description covers the mechanism, the session-scoped state lifetime, how to verify success, and even restates the return object despite an output schema existing. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 0% across host, port, and capture, and the description never mentions any of them. Even though they are connection/infrastructure params with defaults, the description does not compensate for the complete absence of schema documentation, leaving their semantics entirely to inference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

First sentence gives a specific verb, resource, and scope: "Delete the ACTIVE table row natively." It also names the prerequisite sibling (select_table_row) and contrasts its mechanism against copy_table_row, so an agent can place it precisely among the row-operation siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It states the prerequisite ("Select the target row first with select_table_row") and the correct verification path (assert_form_value on PF_TABLE_SNAPSHOT/PF_LAST_ACTION, or capture_screenshot). It gives clear when-to-use context but does not state any when-not-to-use or alternative deletion paths.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden and does so reasonably: it discloses that infobase identity is password-redacted, that run_session data is sourced from the same log as get_test_results and the .ai1c profile, and that 'if given' controls whether pid aliveness is checked. The word 'Snapshot' implies a read with no side effects, though this is not stated outright.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose in the first clause, then tight enumeration of the three aggregated views and the return shape. It is dense but nearly every clause carries information; the return-shape listing is slightly redundant given an output schema exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only diagnostic aggregator with an output schema, the description is complete enough: data sources, redaction, and per-param behavior are covered. It need not restate return values since the output schema exists, and it omits nothing critical for correct invocation.

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

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 for four undocumented params. It does clarify that pid is optional ('if given') and drives an aliveness check, and that env_file relates to the .ai1c profile, but host and port are left to inference via the 'TestClient TPort liveness' and return-shape hints. Partial compensation only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The verb 'Snapshot' plus the resource 'native QA engine's session/run state' is specific, and the description enumerates exactly what is aggregated (connection, run_session, infobase). It references related siblings (get_test_results, infobase_info territory) but never states explicitly why an agent would pick this over test_client_status or infobase_info, so it falls just short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is only implied: the description frames this as a state snapshot, which nudges toward diagnostic/monitoring use, and it notes the run_session data comes from the same log as get_test_results. But there is no explicit when-to-use, when-not-to-use, or named alternative to route the agent.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full disclosure burden and does so well: it explains the log is process-lifetime and in-memory, and that clear=true is a side-effecting option that both reports and resets state, returning a 'cleared' count. Disclosing the destructive reset semantics is exactly the context annotations would otherwise provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose and lifetime before the mechanics, and every sentence is functional. The inline enumeration of the return shape is somewhat verbose, especially since an output schema already exists, but it reads as intentional documentation rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter aggregation tool this covers purpose, data source, lifetime, side effects, and usage trigger. With an output schema present it did not need to detail return values, yet the extra detail causes no harm and nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 0% and the sole parameter has no schema description, so the description must compensate. It does: 'clear=true to report the current roll-up AND reset it (adds cleared = how many were dropped)' fully defines the parameter's meaning, default behavior, and one extra return field.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with explicit scope: 'Aggregate the scenarios run in THIS MCP-server session natively.' It names the contributing tools (run_scenario / run_step / run_write_scenario_tool) and the scope boundary (process-lifetime), so an agent can immediately distinguish it from run_scenario and write_test_report.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives clear context for use: 'Use it after a batch of scenarios to get a single pass/fail report instead of eyeballing each ScenarioResult.' That is a concrete trigger, but it does not name the sibling alternative (write_test_report) or state when NOT to call it, so routing between the two report tools is left to inference.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full behavioral burden and does well: it discloses the prerequisite tooling ('Requires xdotool + a launched display'), the native-vs-protocol distinction, and the conditional shape of each entry ('geometry {x,y,width,height} unless geometry=false'). It does not say what happens on a missing/invalid display or whether the call is strictly side-effect free, but the enumeration framing makes the read-only nature clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and organized as purpose → usage → return shape → sibling disambiguation. It is dense and slightly parenthesis-heavy, but no sentence is wasted and the most decision-relevant content (OS-level vs protocol-level) comes early.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read tool with no annotations, the description covers prerequisites, scoping, parameter meaning, and sibling disambiguation. It redundantly restates the return shape despite an output schema existing, but that costs little and the definition leaves an agent with nothing blocking a correct call.

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

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

Schema description coverage is 0%, so the schema alone would leave both parameters opaque; the description compensates by giving the origin and format of 'display' (from launch_test_client(display=…) status, e.g. ":101") and the effect of 'geometry=false'. This is real added meaning, though it stops short of stating validation or error behavior for a wrong display string.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Enumerate the visible OS windows on the TestClient's X display natively') and pins the scope to the OS/X level rather than the protocol level. It explicitly names the sibling it is not, get_window_list_testclient, so an agent can distinguish the two 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.

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

Gives the concrete use case ('see what the client has open — main window, an opened list/card, a modal dialog') and routes follow-up work to the right siblings ('address an individual window programmatically with activate_window / close_window'). It also states the prerequisites (xdotool plus a launched display), so the when-to-use conditions are explicit.

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

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 discloses that each call opens a FRESH session (so it only lists that session's windows), that the raw replay would be rejected and is grafted onto a live value-read header for matching GUIDs, and that output is decoded/validated against an oracle. This is behavioral context beyond any structured field.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the body is dense and overstuffed with packed parentheticals, a SCOPE block, and marginal asides (e.g. 'Decoded + validated against a genuine analysis oracle (4 windows)'). It is informative but not tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be spelled out, and the description still summarizes them ({count, windows:[{kind,guid,caption}]}). Behavior and scope are well covered for a no-annotation tool; the gap is undocumented parameters, which are largely plumbing defaults.

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

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

Schema description coverage is 0% across four parameters (host, port, capture_dir, manager_templates), all undocumented. The description never explains these parameters, so obscure ones like capture_dir and manager_templates remain opaque; the description does not compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific verb and resource ('Enumerate the 1C-internal windows/tabs open in the TestClient') and immediately contrasts with the sibling get_window_list, explaining the MDI-tab distinction. An agent can differentiate this from get_window_list 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.

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

It explicitly routes the agent: use get_window_list for OS-level X windows, activate_window/close_window to address individual windows, qa_mcp_doctor for a connectivity-only smoke check, and open_link for form-level reads needing a target. The SCOPE paragraph states the fresh-session constraint directly.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose meaningful traits: the password is never echoed (only password_set), the profile is read locally, and a live liveness probe is performed at host:port. It does not state failure behavior when the env file is absent or whether it is strictly read-only, but the disclosure is well above average for an unannotated tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the closing enumeration of the return object ({env_file, env_present, infobase {...}, platform_root, ...}) is redundant since an output schema exists, and phrasing like 'natively' and 'target descriptor' adds jargon without information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because an output schema exists, return values need not be explained, and the description covers source, security handling, liveness check, and a scope limitation. The main residual gap is that it never says when this is preferable to the sibling connection-status tools.

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

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: it identifies env_file as the profile path, infobase_path as the override, and host/port as the TPort liveness target. Defaults and accepted format for infobase_path are still unstated, keeping it short of a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: report TestClient infobase/connection metadata, naming the exact source (.ai1c/*.env profile) and the live TPort check. It is clear what the tool does, but it never contrasts itself with the near-identical sibling test_client_status or get_state, so an agent must infer the split.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is only implied — the agent learns it can override the profile with infobase_path/env_file and that richer handshake metadata is a separate 'decode follow-up'. There is no explicit when-to-use versus test_client_status, qa_mcp_doctor, or com_connector_doctor, and no stated prerequisites.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations to lean on, the description carries the full burden and does so well: the client OUTLIVES the call, it states the returned keys, notes the password is never echoed, explains Xvfb ownership and DISPLAY semantics, the apache stop/restart behavior under manage_apache, and the license opt-in. This is rich behavioral disclosure beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and success condition are front-loaded, and the dense body is organized into natural phases (boot, lifecycle, display, return, licensing). It is information-dense but nearly every clause adds an operational detail, with only mild over-packing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still usefully enumerates the returned keys and the password-redaction guarantee. Given the complexity of a long-running process with Xvfb/apache/license dimensions, it is nearly complete, missing only behavioral detail on headless and wait_sec.

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

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

Schema description coverage is 0% across 10 parameters, so the description must compensate. It meaningfully documents display, manage_apache, use_hardware_licenses, the env profile fields, and mentions port in the boot command, but leaves headless, wait_sec, env_file (beyond its raw default) and the exact env variable mapping under-explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb+resource ('Launch a 1C /TESTCLIENT') plus an observable success condition (wait for its TPort to listen), and the broader text implicitly distinguishes it from attach_test_client and stop_test_client by framing launch/connect/teardown phases. An agent can tell what this does without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It explicitly routes the agent to the lifecycle partners: connect with run_scenario/write_form_value(port=…), then tear down with stop_test_client(pid, xvfb_pid), and explains when display=None vs display=":101" matters. It lacks an explicit contrast with attach_test_client, but the usage context is otherwise clear.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations the description carries the full burden, and it discloses meaningful traits: no-op at the table boundary, session-local form state that must be verified in the same session, and a return shape {base_button, target_button, accepted}. These go well beyond a restatement of the name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The action is front-loaded in the first sentence, but the passage is a dense single paragraph crowded with internal fixture identifiers (PF_MOVE_ROW_UP, ДанныеФормыКоллекция.Сдвинуть) that add implementation noise without helping selection.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be spelled out (though they are). Combined with the prerequisite, boundary no-op behavior, and same-session verification guidance, the definition is nearly complete for this operation.

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

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 for all four parameters. It clarifies the key parameter – direction in {"up","down"} with a worked example – but host, port, and capture remain completely undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

It states a specific verb and resource – 'Move the ACTIVE table row up or down' – and the word 'move' distinct from siblings copy_table_row, delete_table_row, and add_table_row. The purpose is clear, though it is embedded in heavy fixture jargon that partially obscures the plain meaning.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives an explicit precondition ('Select the target row first with select_table_row') and states the verification path ('verify in the SAME session via assert_form_value'). It does not explicitly contrast with copy/delete/add alternatives, but the context of use is clear.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that opening creates a new top-level window (SecondaryFrame), that GUID rebinding occurs automatically, and that success is confirmed by result_marker readback. It does not cover failure modes or permissions, but it is unusually detailed for a test tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded paragraph that starts with the core action. It includes deep technical details about GUID rebinding and navigation replay, which may be more than some agents need, but the information is relevant and not repetitive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations and no schema descriptions, the description must supply almost all context. It covers purpose, behavior, composition with select_table_row, and the output shape (though an output schema exists), but the missing host/port parameter semantics leave a gap for a tool with four parameters.

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

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 for all four parameters. It explains result_marker (a card-specific UTF-16 string) and mentions capture in the context of replaying navigation, but it provides no information about host or port, leaving half the parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Open') and resource ('record CARD') and the mechanism ('drilling into a catalog list row natively'). It distinguishes from sibling tools by naming select_table_row for specific rows and answer_dialog as a similar new-window mechanism.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly says it opens the captured active row's card and instructs to precede with a row-select (compose with select_table_row) for a specific row. This provides clear when-to-use guidance and an alternative path.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full disclosure burden and does so well: it details the exact UI/dialog driving mechanism (main menu -> Файл -> Открыть, GTK chooser, Ctrl+L, Unicode-safe typing via xtest_type_unicode) and the Xvfb/window-manager prerequisite. It stops short of describing failure modes or timing/race behavior beyond settle_sec.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and resource, and the dense parentheticals all carry substantive detail rather than filler. It is verbose and the Cyrillic/step-name asides add length, but almost every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex UI-driving tool with 6 params, no annotations, and an output schema, the description covers the mechanism, prerequisites, verification option, and the return shape. Since an output schema exists, return values need not be re-explained, and the description is complete enough to call the tool correctly.

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

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. It adds meaning for path (Cyrillic-safe typing), display (must be an Xvfb display with WM), and expect_caption (verifies the form opened), but leaves main_menu_x, main_menu_y, and settle_sec unexplained despite being tunable coordinates/timing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: opening an external data processor/report (.epf/.erf) in the running client via the native 1C mechanism. It distinguishes itself from siblings like run_report by stressing 'EXTERNAL' and 'NO external input component, NO config object', so an agent can tell it apart without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives clear usage context by mapping the Gherkin step «Я открываю внешнюю обработку или отчет '<path>'» to this tool and stating a prerequisite (Xvfb display + window manager). However, it does not explicitly name an alternative for related tasks (e.g. run_report for internal reports) or state when NOT to use it.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does meaningful work: assets are 'loaded and structurally checked before a TestClient session opens', missing assets yield 'open-list-navigation-unavailable with protocol_write_attempted=false', and 'A list-open has no business-data mutation or value read-back' signals a safe read-only operation. Gaps remain around session prerequisites (host/port/auth) and re-entrancy, but the failure contract and side-effect profile are unusually well disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and every paragraph touches real behavior, but the prose is dense with backtick-quoted internal tokens and stacked clauses ('the released, version-selected bundled bootstrap and value-read navigation templates') that slow parsing. It is not padded, but it is not cleanly tightened either.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter TestClient tool the description covers the key behavioral contract and, with an output schema present, is not obliged to spell out return values (though it gestures at them anyway). It still omits connection-parameter meaning and sibling routing, so it is adequate rather than complete.

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

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 it only partially does: it clarifies capture (blank vs non-blank) and navigation_templates ('selects a controlled value-read template JSON'), and references base_link/target_link. It says nothing about host, port, or the catalog parameter, leaving three of six parameters undocumented anywhere.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Open a catalog/list window natively through e1cib/list/<path>'), so the core action is unambiguous and distinct from open_card or open_external_processor. However, it never explicitly contrasts itself with siblings like search_list or open_card, leaving the reader to infer the boundary from the resource name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It does explain two operating modes ('Omitting capture... uses the released, version-selected bundled bootstrap' vs 'A non-blank capture preserves the explicit capture-replay compatibility path'), which is genuine conditional guidance. But it never says when to reach for open_list versus alternatives such as open_card, search_list, or advanced_search, so the routing decision is left implicit.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and adds substantial behavioral context: it returns an ordered pass/fail/skipped chain for a defined set of checks, is described as 'secret-safe,' and explains that omitted require_bearer_token defaults to requiring bearer auth for HTTP transports and skipping it for stdio. It still does not explicitly state that the tool is read-only or list required permissions, which leaves a small gap for a diagnostic tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and then efficiently details the check chain and scope exclusions. It is dense but each sentence contributes useful information. Minor redundancy between the first sentence and the following elaboration keeps it from being a perfect 5, but there is no wasted filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. However, the description leaves most of the 8 input parameters undocumented, and with no annotations, it should explain parameter meaning and safety. Given the tool's complexity (8 parameters, several com_* fields), the description is incomplete for correct invocation.

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

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

Schema description coverage is 0% for 8 parameters, so the description must compensate. It only explains one parameter, require_bearer_token, and its default behavior. The other seven parameters (host, port, com_user, com_query, timeout_sec, com_password, com_infobase_path) receive no mention or explanation, leaving most inputs opaque to an agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Run the secret-safe end-to-end qa-mcp setup doctor.' It then enumerates exactly what the doctor checks and explicitly distinguishes itself from sibling diagnostics by stating that 'Platform, COM and private-suite diagnostics are intentionally outside the standalone route.' This gives an agent a precise, unambiguous scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It provides clear context: this is for the standalone qa-mcp setup route, and it lists the checks performed. It also gives an exclusion: Platform, COM, and private-suite diagnostics are outside the route. However, it does not name an alternative tool or state conditions like 'use this before X' or 'prefer com_connector_doctor when Y', so it stops short of explicit when/when-not/alternatives guidance.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does well: it discloses read-only semantics, local write-text rejection before host transport, the authenticated /com/execute hop, and the required QA_MCP_HOST_AGENT / QA_MCP_HOST_AGENT_TOKEN config plus host install prerequisite. It omits timeout/max_rows behavior and any rate or failure-mode detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose in the first sentence, then supplies mechanism and prerequisites. The transport and env-var detail is dense but each sentence carries operational information; no obvious padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the safety/auth prerequisites are covered. But for a 7-parameter tool with no annotations and zero schema coverage, the description leaves parameter meaning entirely undocumented, which is a real gap.

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

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

Seven parameters at 0% schema description coverage, so the description must compensate and largely does not. It never explains infobase_path, user, password, prog_id, max_rows, or timeout_sec; only the query parameter is indirectly touched via the write-rejection note.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Run a read-only 1C query') and specifies the mechanism and data path ('query through the Windows host-agent COM bridge', 'file-infobase data path for model-B installs without OData'). An agent can identify the operation, though it does not explicitly contrast with likely alternatives like advanced_search or read_record.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives clear context for when this path applies ('model-B installs without OData') and states that write-shaped query text is rejected locally. However, it never names an alternative tool for when this path is not available, leaving routing to inference.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and largely meets it: it discloses that the engine opens the form, replays a QUERY sweep, decodes via extract_form_field_values, the value markers used, and that decorations are omitted while Cyrillic fields are covered. It is missing runtime prerequisites (whether a test client must be running) and failure behavior, but the operational detail is unusually rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is an enormous wall of internal-implementation prose (splice headers, 0x97 envelopes, _enumerate_live_fields, bootstrap ack_guid) that overwhelms the agent. Much of it is implementation detail irrelevant to selecting or invoking the tool, and the key usage signal is not cleanly front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return-value explanation is not strictly required, and the description does cover the two non-default modes well. But for a 7-parameter, zero-coverage, annotation-less tool it omits the meaning of host/port/manager_templates and any precondition about the live environment, leaving gaps an agent would need.

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

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

Schema coverage is 0% with 7 parameters, so the description must compensate and only partly does. It meaningfully explains open_link, enable_live, gherkin, and capture_dir ('the one-time per-form capture'), but host, port, and manager_templates receive no explanation anywhere, leaving several parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Introspect a live form into a full element descriptor') and names the equivalent ('the get_form_analysis equivalent'), so the core capability is identifiable. The distinction from data-reading siblings like read_form_value is implied by 'descriptor' rather than stated explicitly, and the intent is partially buried under implementation jargon.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explains what enable_live and open_link do ('introspect ANY form by its nav-link') and the SCOPE caveat that decorations are omitted, which implies when this tool is and isn't appropriate. However it never explicitly compares itself to the many sibling readers (read_form_value, assert_form_value, read_record), so the agent must infer the boundary.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so: it discloses the async/eventually-consistent nature of dynlists, that refresh=True forces an F5 requery and polls until stable so value=None is trustworthy, that refresh=False opts out, and that table-resolution failures emit structured diagnostics rather than a false empty. This is exactly the behavioral context an agent needs and gets from nothing else.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the key usage constraint are front-loaded, but the definition is bloated: an embedded Russian-language narrative, a MECHANISM paragraph justifying the replay approach, and live-verification examples that inform an implementer more than a caller. The refresh/consistency content earns its place; the replay-justification prose does not.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-complexity tool with an output schema (which covers the returns, redundantly re-listed here), the description is quite complete on behavior and caveats. The remaining gap is that three connection/capture parameters are undocumented, and no permission or authentication prerequisites are stated.

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

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 it does so for four of seven parameters (column, open_link and table with examples, refresh with default semantics). host, port, and capture_dir are never explained, leaving real gaps. Because the schema provides no per-parameter help, this is only partially adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb (read), a precise resource (current/first row value of a dynamic-list column), and a specific context (catalog LIST form). It then explicitly differentiates itself from the sibling read_table_cell by scoping that tool to FORM tables, so an agent can route correctly 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.

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

It gives an explicit alternative (read_table_cell for FORM tables) and a conditional rule for refresh (True default vs False for absence assertions). It does not, however, address when to prefer this over the other list-reading siblings (read_list_row, read_list_grid, read_list_grid/search_list), leaving some routing ambiguity.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so extensively: eventual consistency of 1C dynamic lists, default refresh/poll-until-stable semantics, the meaning of a reported '0 rows', wait_for_rows blocking behavior, hierarchical-vs-flat view defaults, table-resolution failure diagnostics that do NOT run a wrong-table replay, and the one-grid-read-per-fresh-client constraint. This is exactly the behavioral context an agent needs for a stateful, capture-replay tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core is correctly front-loaded in the first sentence, and the labeled paragraphs (FLAT, CURRENCY, Mechanism) aid scanning. However the 'Mechanism:' paragraph — message-ids, action GUIDs, socket materialisation, sequence bumping — is internal implementation detail that does not help an agent decide or invoke correctly, and the description is long overall.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter, unannotated, high-complexity capture-replay tool, the definition covers invocation conditions, view-mode pitfalls, consistency behavior, and failure modes. An output schema exists so return-shape documentation is optional, and the description's return summary is a bonus rather than a necessity; the minor gap is the undescribed host/port/capture_dir parameters.

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

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

Schema coverage is 0% across 10 parameters, so the description must compensate — and it explains the important ones: open_link (with a concrete example), columns, max_rows, flat (with default and effect), table, refresh, wait_for_rows, and list_refresh semantics. Only host/port and capture_dir are left largely unaddressed, which keeps it short of a 5 given the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with explicit scope: 'Read MANY ROWS × columns of a dynamic list (the whole visible grid) in ONE call'. It also names the siblings it is not (read_list_row, read_list_column, read_table_cell) and states the axis of difference (many rows vs single row vs single cell vs form tables). An agent can pick this tool 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.

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

Explicit when/when-not guidance: use this for the whole grid, use read_list_row/read_list_column/read_table_cell for narrower reads. It also gives conditional guidance for sub-parameters (set flat=True for hierarchical catalogs, refresh=False for absence assertions, pass table to select explicitly). Routing is unambiguous.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it discloses the cold-client boundary (one row read per fresh launch_test_client), session behaviour (message-id kept, sequence bumped), the default refresh/requery semantics, and the verified matching path. It stops short of stating auth/permission needs or error/failure behaviour, so not a full 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence, which is good, but the text is long and includes implementation/testing trivia (the 'splice of the FORM-table' replay discussion, live-verified vs OData details) that is not needed to invoke the tool. Conciseness is adequate but leaks developer reasoning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, yet the description even summarises the return shape. Combined with the routing guidance and refresh semantics, an agent has enough to call it correctly; the only gaps are the undocumented host/port/capture_dir parameters.

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

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

Schema coverage is 0%, so the description must compensate; it explains open_link, columns, where, and refresh with examples and default semantics. It does not explain host, port, or capture_dir, leaving three of seven parameters undocumented, which keeps it from a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read SEVERAL columns of a dynamic-list row in ONE call') and pins the scope with concrete examples (open_link, columns). It explicitly differentiates itself from siblings by naming read_list_grid (iterate all rows), read_list_column (single cell), and read_table_cell (FORM tables).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Names the alternative tools and the exact condition that selects each one, so the agent can route without opening schemas. It also gives explicit when-to-use guidance for the 'where' parameter (omit for first row, pass to position by value).

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so thoroughly: it discloses the reference-link/URL encoding mechanism, the auto-encoding of the dashed UUID to the e1cib hex token, the exact return shape, and the cold-client failure mode (field_count 0 with element_count > 0, and that re-opening the same record does not help). These are non-obvious behavioral traits an agent could not infer from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence front-loads the purpose well, but the body is dense and overstuffed with bilingual examples, encoding history, and a live-verified sample that go beyond what an agent needs to call the tool. It earns more of its length than a typical spec, yet still reads as heavier than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still supplies the failure-mode and pre-warming guidance that the schema cannot express, and the complexity of native COM automation warrants it. For this tool's complexity, nothing an agent needs to invoke it correctly — encoding, required inputs, and cold-client caveat — is missing.

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

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 it does for the semantically important parameters: record_type (metadata full name, e.g. Справочник.Товары), ref (natural dashed UUID form auto-encoded, or raw 32-hex token), and gherkin (adds a Gherkin state block). The remaining four parameters (host, port, capture_dir, manager_templates) are undocumented, but they are infrastructure defaults rather than the values an agent must reason about.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource: read the object-attribute VALUES of an existing populated catalog/document record, and explicitly frames it as 'natively (no per-form capture)'. This differentiates it from form-based readers in the sibling set such as read_form_descriptor and the form-value reads. An agent knows exactly what data this returns without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explains the operating condition for success (warm the client with a different record before reading a large cold record) but never names a sibling tool or an explicit 'use X instead when Y' rule. The 'no per-form capture' phrase implies an alternative but leaves the selection to inference. Adequate, but not the explicit when/when-not routing a 5 requires.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose meaningful behavior: the manager never sees cell text in binary render, a targeted read re-evaluates the cell, and the flow opens a form and runs a report before navigating. It also names the return shape, though it omits permissions or re-entrancy concerns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is dense, jargon-heavy and mixes English with Cyrillic, making it harder for an agent to parse quickly. Several clauses (wire-decode details, byte-shape `0x9a<len>`) expand without changing the calling decision.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be detailed (though they are). For a tool with deep internal protocol nuance and zero annotation coverage, the definition covers mechanism well but leaves the majority of parameters unexplained, leaving gaps an agent must guess at.

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

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

Schema coverage is 0% and only the `address` parameter is meaningfully explained (R1C1 notation, arbitrary length, navigate frame resizes). The other five parameters — host, port, field, capture, captured_address — are undocumented in both the schema and the description, so the compensation is only partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read a spreadsheet CELL by address natively') and contrasts it with the binary .mxl wire-decode approach, which clarifies what the tool is not. It does not, however, distinguish itself from close siblings like read_table_cell or read_record.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explains the internal mechanism (targeted in-client read, replayed form/report flow) but never states when to pick this tool over read_table_cell, read_list_row, or read_record. There is no when-to-use, when-not-to-use, or alternative routing guidance.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that it opens the suite fixture form by default, that 'open_link' can target any form, that groups are discovered from the live descriptor, and that a DYNLIST may have no active current row (value None). It does not mention permissions required or rate limits, but for a read operation the disclosed behavior is substantial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and packs much into a single block, but it front-loads the core purpose. However, it mixes Cyrillic identifiers, JSON return format, and scope notes in a way that reduces readability, and some details (e.g., the exact template path) are verbose without adding decision-relevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, yet the description still lists the return shape. For a 7-parameter tool with 0% schema coverage and no annotations, the description covers the key read semantics and the important DYNLIST caveat, but leaves half the parameters unexplained, which is a completeness gap.

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

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 for 7 parameters. It only explains 'table' and 'column' by name and 'open_link' with an example, leaving 'host', 'port', 'capture_dir', and 'manager_templates' entirely undocumented. With 0% schema coverage and 7 parameters, this is a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb+resource ('Read the CURRENT ROW's value of a form-table cell') and names the 1C equivalent ('ТаблицаФормы … ТекущиеДанные'). It distinguishes itself from 'read_list_column' by noting the DYNLIST case where no current row exists, making the scope boundary clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description says to use 'open_link' to read on any form and explicitly routes the agent to 'read_list_column' when a dynamically opened list lacks an active current row. It provides the default (suite fixture form) and the alternative, but does not state exclusion conditions beyond the DYNLIST scenario.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and largely meets it: it discloses the read is capture-free, the wire envelope `cb 53 9a <byte-len> <UTF-8>`, the return shape, and honestly flags that multibyte Cyrillic decoding is unproven. Remaining gaps (permissions, error behavior) are minor for a read tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose in the first sentence and keeps every subsequent clause informative (envelope format, return shape, caveat). It is dense and jargon-heavy, but the length is largely justified by the tool's low-level nature.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description usefully still names the return keys; combined with the behavioral and protocol details it gives an agent enough to invoke the tool correctly. Only the unexplained `host`/`port` and absent permission/error notes are minor gaps.

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

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. It explains `expected` (assert a message is present) and gives some meaning to `capture` ('the genuine flow from `capture`'), but leaves `host` and `port` undocumented beyond convention. Partial compensation, not full.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource: 'Read the user messages a form emits', and further pins its function as 'the capture-free ASSERTION read' for «нет сообщений пользователю» and `Сообщить` output. This is far more precise than a tautology, though it does not explicitly name a sibling tool it must not be confused with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

States the concrete contexts for use: asserting 'нет сообщений пользователю' and reading `Сообщить` output, plus the `expected` mechanism for asserting a specific message. It gives clear positive guidance but names no alternative tool or explicit when-not condition.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it flags deprecation, explains the exclusive-lock failure mode, describes per-role outcomes (read/denied/error plus http and ok flags), and warns that real role differences likely need external provisioning. It does not detail auth/permission requirements for the call itself or pagination/size limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The deprecation warning is correctly front-loaded, but the body is a single dense run-on sentence packed with parentheticals, mixed scripts, and em-dash asides. It also restates the full return object even though an output schema exists, which is partly redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is technically optional, and the description covers deprecation, the lock caveat, and provisioning constraints thoroughly. The main gap is the three non-roles parameters (entity_set, filter, base_url) that remain undocumented at 0% schema coverage.

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

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. It does document the roles array item shape ({label, user, password} with an optional expectation {expect_access, min_count}), but entity_set, filter, and base_url are left entirely unexplained in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it runs the SAME data-layer read under several credentials/roles and reports per-role access plus record count. No sibling tool performs role-based access matrices, so the scope is unambiguous even before opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives explicit when-not guidance (deprecated for a test-client-held base under an exclusive lock, valid only against a separately published non-exclusive endpoint) and notes that genuine role differences require out-of-band provisioning via admin-mcp, outside qa-mcp's read-only scope. It stops short of naming a specific sibling tool as the in-scope alternative, so it is strong but not a full when/when-not/alternative triad.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and mostly delivers: it says the click fills the spreadsheet ON THE SERVER, sets PF_LAST_ACTION="PF_RUN_REPORT", and that cell content ships as a 1C-packed binary .mxl blob (not strings, not zlib) so per-cell reading is deferred. It omits preconditions (attached test client, required open form) and permission needs, keeping it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The lead sentence is front-loaded and correct, but the body is a dense wall of low-signal detail — raw hex byte offsets ('88 82 81 20 20 20'), .mxl format lore, and parenthetical asides — that outweigh the actionable content and make the description hard to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and return values are also stated, so that burden is covered. But for a relatively complex native-run tool, the definition never states prerequisites (which client/form must be active) or failure behavior, leaving a meaningful gap for correct invocation.

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

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

Schema coverage is 0% for all 4 parameters. The description only gestures at two of them ('setup from capture', the PF_RUN_REPORT default for command) and never explains host or port, so it does not compensate for the documentation gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Run a report / fill a ТабличныйДокумент natively') and even names the mechanism (a FORM-COMMAND click in the click_command family), so an agent can place it against siblings. It stops short of 5 because the purpose is buried under internal implementation detail and never crisply contrasts itself with run_scenario or a direct click_command call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

'Replays the genuine setup from capture + the command click' is the only usage hint, and it is told to verify via capture_screenshot or the PF_LAST_ACTION marker. There is no explicit when-to-use / when-not-to-use versus click_command or the other run_* tools, so an agent must infer that this is the report-specific path.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so unusually well: it discloses that OPEN steps execute live with no capture (window-resolved pass condition), that other action steps re-target a captured frame replayed GUID-rebound to the live session, and that frames are matched by marker and pinned via ordinals. The failure mode without action_capture is stated outright.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the feature_text/scenario_json source are front-loaded, and no sentence is pure filler — each adds execution semantics. However, the prose is a dense wall of parentheticals, backticks and guillemets that is hard to scan for the key distinctions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter tool with an output schema (so return values need no explanation), the execution model, capture requirements and step-support matrix are covered well. The main gap is the prerequisite chain — it says 'against a running /TESTCLIENT' but never points at launch_test_client/attach_test_client, and under-explains the remaining connection/session parameters.

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

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

Schema description coverage is 0% across 10 parameters, so the description must compensate. It adds real meaning for action_capture, action_input_value, action_ordinals, and feature_text (multi-scenario → callees), but leaves host, port, capture_dir, single_session, and manager_templates entirely undocumented. Roughly half the parameters remain opaque.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource ('Run a scenario ... through the native Python TestManager against a running 1C /TESTCLIENT') and the multi-scenario/callee registration detail implicitly separates it from the step-level sibling run_step. An agent can tell this is a full scenario runner, not a single-step executor, without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives a clear conditional ('to EXECUTE those pass ``action_capture``') and an explicit exclusion ('Without ``action_capture`` only read/assert/data/skip/subscenario/open steps run; other action steps report unsupported'), which is strong when-to-use guidance. It never names an alternative tool such as run_step or run_write_scenario_tool, so the routing is inferred rather than stated.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and 'read step' only implicitly signals a non-mutating operation. It says nothing about the host/port connection requirement, what capture_dir or expect_contains actually do, or how failures surface, which is a real gap for a tool with connection parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler, and the enumerable kinds are placed where the agent will read them first. It is efficient, though its brevity is partly under-specification rather than discipline.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. However, for a 7-parameter tool with no annotations and 0% schema coverage, the description leaves connection setup, marker/capture semantics, and error behavior undocumented, which is inadequate.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate and largely does not. It clarifies the 'kind' enum values but leaves host, port, marker, capture_dir, expect_contains, and manager_templates entirely unexplained in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Run) and resource (a single read step) and enumerates the three valid step kinds, which lets an agent map the required 'kind' parameter. It stops short of distinguishing this tool from siblings like run_scenario or run_write_scenario_tool, and 'natively' is unexplained jargon.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

No guidance on when to choose this over run_scenario, run_write_scenario_tool, or search_for_steps, all of which appear related. The agent is left to infer that this executes one step in isolation, but nothing states that condition or any prerequisite.

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

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 reasonably well: it discloses that values actually commit (verified by read-back), that steps may target different fields via step.marker, and that non-write steps are reported as unsupported. This is substantive commit/verification context. It stops short of stating prerequisites or failure behavior, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The verb and write-scoping are front-loaded, which is good. But the single dense paragraph is cluttered with backticks, embedded Russian Gherkin, and internal jargon (NativeWriteSession, capture-free element addressing), making it heavier than the information content warrants.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is not required, and the description does sketch the ScenarioResult preview. But for a 15-parameter tool with zero schema coverage and no annotations, the definition leaves far too many controls undocumented for an agent to invoke it confidently.

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

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

There are 15 parameters with 0% schema description coverage, so the description must compensate and largely does not. It explains the conceptual roles of base_field, step.marker, and the scenario_json/feature_text alternatives, but most parameters (host, port, save, display, open_link, input_offset, default_value, captured_value, require_cleanup, cleanup_evidence_json, persistence_verification_json) are never described. The coverage gap is too large for a 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: it runs a WRITE scenario (Gherkin input_text steps or scenario_json) natively through a commit-capable session. It distinguishes itself from the broad run_scenario/run_step siblings by emphasizing WRITE/commit semantics and read-back verification. The jargon density makes it harder to parse than ideal, but an agent can tell it targets write scenarios specifically.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It implies usage by declaring the write scope and noting that 'non-write steps are reported unsupported', which is a useful when-not signal. However, it never explicitly names an alternative sibling (e.g., run_scenario, run_step, write_form_value) or the condition that should route the agent to it instead. Guidance is implied rather than stated.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and mostly succeeds: it discloses the filtering semantics, the empty-returns-all default, and crucially that the library is derived from the transpiler's STEP_PATTERNS so it 'exactly matches what transpile / run_scenario execute'. It doesn't state whether the result is cached or how large the library is, but the key behavioral guarantees are present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and efficient overall, but it is one dense paragraph and the final sentence restating the return object duplicates what the output schema already defines. Slightly more padding than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so restating return values was optional, yet the description otherwise covers the gaps that matter: purpose, filter behavior, provenance, and usage. Complete enough for an agent to call correctly, with only minor redundancy.

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

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

Schema coverage is 0% (the single 'keywords' param is documented only as a bare string with a default), so the description must compensate and does: 'each whitespace-separated token must appear, case-insensitive; empty returns all'. This fully specifies the filter semantics an agent needs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Discover the supported Gherkin step vocabulary' / 'the qa-mcp step library') and enumerates what each entry contains. It clearly separates itself from siblings like transpile and run_scenario by describing what this tool provides versus what those execute.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly names the use case ('Use it to author features for qa-mcp') and explains the relationship to the alternative ('transpile then flags any unmapped lines'). It gives clear context but stops short of stating when-not to use it or naming other search alternatives.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does substantial work: it states incremental filtering via searchOnInput, that there is no clean value read-back, that a search reports no row count so it is refresh-only with no poll-until-stable, and that list_refresh records the refresh method. This is rich behavioral disclosure beyond the schema. It stops short of 5 only because it never addresses auth/permission or failure-mode behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action, and headings (CURRENCY, Returns) aid scanning. But it is heavily padded with low-value implementation detail — hex byte layout ('e0 41 81 81 b7 <char-count><utf-16le><space pad>') and buffer-machinery narration — that does not help an agent select or invoke the tool. Several sentences do not earn their place for the invocation decision.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be spelled out, yet the description still lists the response keys. Combined with the refresh semantics, read-back limitation, and near-complete parameter coverage, an agent has enough to call this correctly. It is close to complete for a no-annotation mutation-ish tool, lacking only explicit auth/prerequisite context.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate, and it largely does: it explains value (the search string), search_field (the SearchStringAddition element), capture (the genuine setup replay that typed captured_value), captured_value (the seed typed into the search box), and refresh (force requery vs opt out). Only host/port are left unaddressed, but those are obvious connection defaults, so the behavioral meaning of the search-relevant parameters is covered.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb+resource+scope: 'Filter a dynamic list by a SEARCH STRING natively,' then clarifies it types into the search-string addition and filters incrementally. It even contrasts itself against the shared machinery of set_reference_field, so an agent can distinguish it from that sibling. It does not, however, explicitly compare against the other search-like sibling (advanced_search), so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage context is present but implied: the CURRENCY section explains when refresh defaults on/off and why, and it notes that confirmation must be done via capture_screenshot. However, there is no explicit 'use this instead of advanced_search/choose_from_list when...' routing, and no prerequisites section. Adequate but leaves the alternative-selection decision to inference.

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

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 it does so richly: it states the operation is a table-level command (not OS input) that is accepted, and it discloses that the multi-selection is transient focus state that any focus-changing command collapses back to the active row. It even names the non-collapsing read path, which is exactly the kind of destructive/side-effect context annotations would otherwise have to carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Although the purpose is front-loaded, the body is a dense multi-hundred-word block mixing Russian and English, with run-on sentences and nested asides. Much of the protocol-internal detail could be trimmed or moved to documentation, so the definition is bloated rather than economical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a protocol-driven 1C automation tool with no annotations and an output schema ({base_button, target_button, accepted}), the description covers the important behavioral traps an agent must know (transient selection, single-session capture) fairly completely. The main gap is the absence of explicit when-to-use guidance and parameter meaning.

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

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

Schema coverage is 0% across three parameters (host, port, capture) with no descriptions in the schema. The description never explains what these parameters mean or how the 'capture' default relates to the referenced capture-on-demand behavior, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause 'Select ALL rows of the table natively (multi-select)' states a specific verb+resource and scope, and the 'ALL' / multi-select framing distinguishes it from the singular sibling select_table_row. Beyond that first clause the purpose is buried under protocol internals, but the core action is identifiable without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

There is no explicit 'use this when…' guidance and no routing versus select_table_row or other selection tools. The only actionable usage note is the implicit constraint that select-then-act must be captured in ONE session, which is a caveat about mechanics rather than a when-to-use-vs-alternative statement.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and largely meets it: it discloses the mutation mechanism (replays the capture setup, re-points the search value), the side effect (the targeted row becomes ACTIVE), and the return shape {row_match, accepted}. It stops short of stating permissions, failure modes, or behavior when no row matches.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and single-paragraph, but dense with low-signal implementation trivia ('both length-prefixed strings in the genuine command', 'fixed-width') that taxes the reader more than it informs tool selection.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values are arguably redundant, yet the description's real gaps are the six undocumented parameters and absent guidance on failure or precondition states for a 9-parameter tool.

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

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

Schema coverage is 0% across 9 parameters. The description clarifies row_match, its relationship to captured_row_match and capture, and implies base_column, but leaves host, port, captured_value, commit_partner_field, and commit_partner_value entirely undocumented in both prose and schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause states a concrete verb and resource: 'Position the active row of a table to the row whose column equals row_match.' However, the core purpose is buried under implementation jargon ('natively', 'length-prefixed strings in the genuine command', 'fixed-width'), and it never names a sibling tool to differentiate itself from add_table_row, copy_table_row, or delete_table_row.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explains how to verify a selection (assert_form_value) and how to chain into set_table_cell, but gives no guidance on when to select a row vs. an alternative approach, nor any prerequisites or conditions for use.

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