Skip to main content
Glama

Update Wiki grid row

wiki_grids_rows_update
Idempotent

Pin or color a single grid row to highlight it or move it to the top; cell values remain unchanged.

Instructions

Pin or colour one grid row (cell values are set by grids_cells_update).

Repeating the same call leaves the same row (idempotent). The reply is a bare acknowledgement without the new revision (read it with grids_get); revision is accepted but not enforced. Yandex does not document this operation (it is in the live OpenAPI only) and may change it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYes``pinned`` and/or ``color`` to set; ``revision`` is optional.
row_idYesId of the row to pin or colour.
grid_idYesThe grid's permanent UUID4 id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.67.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses idempotency behavior, that the response is a bare acknowledgement lacking the new revision (and that grids_get is needed to read it), that revision is accepted but not enforced, and the significant caveat that the endpoint is undocumented and may change. These are exactly the traits an agent cannot infer from readOnly/idempotent/destructive hints.

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

Conciseness4/5

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

Front-loads the mutation purpose, then packs idempotency, response shape, and the undocumented-API warning into a few tight sentences. Dense but every sentence earns its place; no filler.

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?

With no output schema, the description compensates by describing the return value (bare acknowledgement, revision absent) and how to retrieve the revision. Combined with the undocumented-endpoint warning, an agent has everything needed to call and interpret this correctly.

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 100%, so the baseline is 3. The description still adds value by clarifying that revision is accepted but not enforced (which matters for whether an agent must fetch a fresh revision) and confirms the pin/color intent of the body, lifting it above baseline.

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+resource ('Pin or colour one grid row') and immediately delineates scope by noting cell values are set by grids_cells_update. An agent can distinguish it from wiki_grids_rows_move, wiki_grids_rows_remove, and wiki_grids_cells_update 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 Guidelines4/5

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

Explicitly routes cell-value edits to the sibling grids_cells_update, which is the key usage boundary for this tool. It does not spell out when-not to use it beyond that, but the sibling routing is clear and actionable.

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

Deploy Server

Other Tools