Skip to main content
Glama

set_table_date_cell

Set a grid date cell on the active row using the calendar picker via mouse, since masked date editors reject direct text input. Locate the cell on screen and commit the picked date.

Instructions

Set a grid DATE cell to date (DD.MM.YYYY) on the ACTIVE row natively, with the cell located ON SCREEN (no hardcoded coordinates). A 1C date grid cell rejects text/keystroke SET (masked editor); it is settable only by MOUSE through the calendar picker. This tool: (1) protocol-activates the cell (the shipped table-cell write_block — activate+SET, no commit — so the inline date editor and its calendar dropdown button appear), (2) screenshots and LOCATES the calendar button by template-matching the shipped glyph (ImageMagick compare -subimage-search via locate_calendar_button), (3) drives the calendar by mouse — click the dropdown, then the month, then the day — using the popup month-list / day-grid origins DERIVED from the localized button center (fixed deltas, calendar_month_cell / calendar_day_cell geometry), then commits (Return). Returns {column, requested_date, localized, button_xy, month_origin, day_origin, status, verified_by, screenshot, activation_screenshot}. When the button cannot be located it returns status="blocked" and does NOT click guessed coordinates; status="set" when the pick committed (the calendar closed) and "set_calendar_open" if the calendar is still visible after the pick.

YEAR is navigated when the target year differs from the cell's CURRENT year (the calendar opens on it): the ‹/› arrows step the month, so the year uses the « ▼» dropdown (current at the top, current+k below; clicked by row, chained in steps of 3 for larger forward offsets). The current year = from_year if given, else today (correct for an EMPTY cell, which opens on today) — pass from_year for a populated cell whose year differs from today. Backward years (target < current) are not yet supported (the dropdown lists forward only) and return status="blocked".

VERIFICATION is the SCREENSHOT: a mouse-set date cell has no protocol SET echo (the value enters via the calendar, not a wire SET) and the in-form value is not protocol-readable without a save, so the active cell showing the picked date in screenshot is the proof.

REQUIRES an X display with the client laid out by a window manager (matchbox; started here when manage_wm) so the cell/calendar geometry is stable, plus xdotool (XTEST mouse) and ImageMagick.

CONFIG-AGNOSTIC path — pass open_link (a document's e1cib/data/Документ.X?ref=… ref) to set the date on ANY real document form's tabular date cell with NO per-form capture (no capture / write_block). The engine brings the form FOREGROUND, activates the cell ON SCREEN by double-clicking it — located from the date column's on-screen header column_title (e.g. "Дата", subimage-search; the form descriptor has no pixel bounds) or the explicit cell_x/cell_y — and reuses the same calendar pick. row_offset (≈ one grid row, 28 px) steps from the header to the first data row; column is the date column NAME (for the result).

foreground selects how the form is brought to the active tab: "listreplay" (DEFAULT, fixture-FREE, config-agnostic) replays a genuine cold catalog-list-open sequence retargeted to open_link (no bundled fixture — works on any config); "fixture" is the legacy primer (the bundled fixture render-push frames + prime). prime only applies to foreground="fixture".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYes
hostNo127.0.0.1
portNo
primeNo
tableNoPF_TABLE_ITEMS
cell_xNo
cell_yNo
columnNoPF_TABLE_DATE
captureNogenuine-card90-table-20260617/traffic-selfcontained
displayNo:89
from_yearNo
manage_wmNo
open_linkNo
foregroundNolistreplay
row_offsetNo
settle_secNo
base_columnNoPF_TABLE_TEXT
column_titleNo
captured_valueNoCELLAA
commit_partner_fieldNoPF_EDIT_STRING
commit_partner_valueNoC90CMT

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/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 richly: it discloses the exact status values ('blocked', 'set', 'set_calendar_open'), that it never clicks guessed coordinates, the X-display/xdotool/ImageMagick prerequisites, the mouse-only limitation, the backward-year gap, and that the screenshot is the sole verification of success.

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 and the numbered (1)(2)(3) sequence is logical, but the text is heavy with internal implementation trivia (ImageMagick 'compare -subimage-search', write_block internals, fixed-delta geometry) that does not help an agent decide or invoke. Length is defensible for the complexity but several sentences are documentation-of-the-implementation rather than tool guidance.

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

Completeness5/5

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

An output schema exists, so return values need not be re-explained, yet the description also enumerates the return fields and their meaning. Given the tool's complexity, it covers preconditions, failure modes, the two setup paths, and verification, leaving nothing an agent needs in order to drive it correctly.

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

Parameters3/5

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

Schema description coverage is 0% and there are 21 parameters, so the description must compensate. It meaningfully explains date format, open_link, row_offset ('≈ one grid row, 28 px'), column, column_title, from_year, foreground and prime, but leaves host, port, display, table, base_column, capture, captured_value, commit_partner_field/value and settle_sec unexplained, so the compensation is only partial.

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

Purpose4/5

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

The opening sentence states a specific verb and resource ('Set a grid DATE cell to date (DD.MM.YYYY) on the ACTIVE row natively') and the following sentence explains why a date cell needs a dedicated mouse path instead of a keystroke SET. It never names the sibling it substitutes for (set_table_cell, write_form_date), so differentiation is inferential rather than explicit.

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

Usage Guidelines4/5

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

Strong conditional guidance: pass open_link for the config-agnostic path, pass from_year for a populated cell whose year differs from today, and foreground='listreplay' (default) vs 'fixture' with prime only applying to fixture. It states when the tool is unusable (backward years return status='blocked'), but gives no direct when-to-use-this-over-X comparison against the sibling date/cell setters.

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