qa-mcp

read_list_grid

Read all visible rows and columns from a 1C dynamic list in one call, stepping through the grid up to a row limit and refreshing it to return stable data.

Instructions

Read MANY ROWS × columns of a dynamic list (the whole visible grid) in ONE call. Opens the list at open_link (e.g. e1cib/list/Справочник.Товары), reads the first row's columns (e.g. ["Код", "Наименование"] of the resolved dynlist table), then steps «перехожу к следующей строке» and reads again, up to max_rows rows or end-of-list. By default the table is resolved from the live descriptor; pass table to select explicitly. Returns {table, nav_link, row_count, rows: [{column: value}, …], list_refresh, table_resolution}.

flat (default False) reads the list's CURRENT view/sort order. A HIERARCHICAL catalog (e.g. Товары) defaults to a grouped view, so the grid then exposes only the TOP-LEVEL folders (Обувь/Продукты/…). Set flat=True to first switch the list to flat «Список» view (the standard catalog-list-form «ФормаСписок» view-mode command, baked into the genuine capture) so NESTED items are read too — live-verified on Товары (flat -> Bosch1234/Sony К3456P/Босоножки/… nested rows, codes vs OData). flat selects the capture; pass capture_dir to override explicitly.

CURRENCY: a 1C dynamic list is async/eventually-consistent, so refresh=True (default) forces an «Обновить»/F5 requery and polls-until-stable before reporting — a freshly-created record shows up and a reported 0 rows only ever means a genuinely empty list. refresh=False opts out (records "no refresh applied") for an absence assertion. wait_for_rows=N blocks until at least N rows are read or the bounded poll timeout elapses (list_refresh.wait_for_rows_met reports which). list_refresh records the refresh method + poll outcome. Table-resolution failures return structured list-table-* diagnostics and do NOT run a wrong-table replay or call the list genuinely empty.

Mechanism: a genuine next-row capture replayed cold (faithful full-replay through the first read — which for the flat capture also replays the view-switch — then the genuine go-to-next-row block, the decoded next-row action GUID d267315b…, replayed + the reads, all on the one materialised socket, message-id kept + sequence bumped). Live-verified the cursor advances. One grid read per fresh launch_test_client (the cold-client boundary). Use read_list_row for a single row (or a row by value), read_list_column for a single cell, read_table_cell for FORM tables.

Input Schema

TableJSON Schema

Name	Required	Default
`flat`	No
`host`	No	127.0.0.1
`port`	No
`table`	No
`columns`	Yes
`refresh`	No
`max_rows`	No
`open_link`	Yes
`capture_dir`	No
`wait_for_rows`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full 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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server