Skip to main content
Glama

read_list_row

Reads multiple columns of a specific dynamic-list row in one call, optionally targeting the row by column value first; returns the row's data.

Instructions

Read SEVERAL columns of a dynamic-list row in ONE call. Opens the list at open_link (e.g. e1cib/list/Справочник.Товары) and reads each name in columns (e.g. ["Код", "Наименование"]) of the standard dynlist table Список. Returns {table, nav_link, row: {column: value}, list_refresh} (+ where when given).

where selects the ROW: omit it to read the FIRST (current) row; pass a single {column: value} (e.g. {"Наименование": "Молоко"}) to position the list to the row WHERE column == value first — the «в таблице "Список" я перехожу к строке: | col | value |» equivalent — then read THAT row. The where-row path is a faithful full-sequence replay of a genuine DYNLIST go-to-row-by-value capture (a splice of the FORM-table «перехожу к строке» onto a live dynlist did NOT reposition; the full-sequence replay does), value retargeted in-frame; live-verified on Товары (Наименование=Молоко -> Код 000000026 vs OData). Matching by «Наименование» is the verified path. One row read per fresh launch_test_client (the cold-client boundary), reading all requested columns inside the one materialised session (message-id kept, sequence bumped). CURRENCY: refresh=True (default) forces an «Обновить»/F5 requery + poll-until-stable so an all-None row is only ever a genuinely empty row, not a not-yet-loaded list; refresh=False opts out. For iterating every row use read_list_grid; read_list_column for a single cell; read_table_cell for FORM tables.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostNo127.0.0.1
portNo
whereNo
columnsYes
refreshNo
open_linkYes
capture_dirNolistform-read

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/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 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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters4/5

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

Schema coverage is 0%, so the description must compensate; 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.

Purpose5/5

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.

Usage Guidelines5/5

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.