Skip to main content
Glama
logisky

logisheets-mcp

by logisky

set_field_rule

Set declarative rules on a spreadsheet field: define value formulas, validation, or editability. Pass null to clear existing rules; omit to leave them unchanged.

Instructions

Attach declarative rules to a field. All three rule kinds (value_formula, validation, editability) are optional — pass only the ones you want to change. Omit a kind entirely to leave it untouched on this field; pass null to explicitly clear an existing rule.

Placeholders supported in formulas: #FIELD("name") — the same row's cell in field "name" #FIELD("name", "key") — field "name" on the row carrying that key, in THIS SAME block #KEY — the row's key value (quoted as a string literal) #PLACEHOLDER — the cell itself (validation/editability only)

The two-argument #FIELD is the only way to reach another row of the cell's own block: BLOCKREF is refused there (it depends on the whole-block vertex, so it would close a cycle). Use it for share-of-total or index-to-a-base-row columns, e.g. "=#FIELD("amt")/#FIELD("amt","TOTAL")". The other row is named by KEY, never by position — there is no "previous row" form, because rows can be reordered and inserted into, so a positional address would silently come to mean a different row. A running total (each row reading the row above) therefore has no rule form; write that column as ordinary cells outside the block. A rule that resolves onto the cell it is defining is rejected, as is a plain coordinate (A1/C3) landing inside the block — in a template a coordinate does not shift per row, so on the first row it would point at the cell being defined.

Engine behaviour after this call:

  • value_formula → cells in the field become engine-computed (no direct writes). Every row's formula is re-materialized.

  • validation → a ShadowKind::Validation shadow is auto-installed on every row; warning markers refresh.

  • editability → a ShadowKind::UserEditable shadow is auto-installed on every row; the host permission patch reads it to gate writes.

Leading "=" on the formula body is optional; omit or include either way.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
blockYes
fieldYes
validationNoBoolean formula, e.g. "#PLACEHOLDER>=0". Pass null to clear; omit to leave existing untouched.
editabilityNoBoolean formula, e.g. "=#FIELD(\"status\")<>\"locked\"". Pass null to clear; omit to leave existing untouched.
value_formulaNoFormula template, e.g. "=#FIELD(\"qty\")*#FIELD(\"price\")", or "=#FIELD(\"amt\")/#FIELD(\"amt\",\"TOTAL\")" to divide by a named row of the same block. Pass null to clear; omit to leave existing untouched.
Behavior5/5

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

The description thoroughly explains the engine behavior after the call for each rule kind (re-materialization, shadow installation, permission gate). It also discloses rejection criteria for self-referencing rules and coordinates landing on the block, and notes that leading '=' is optional—all beyond the annotations, which only provide readOnlyHint and destructiveHint.

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

Conciseness5/5

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

The description is long but dense with essential information. It is front-loaded with the core purpose and optionality, then logically progresses to placeholder syntax, cross-row references, constraints, and engine behavior. Every sentence contributes value, with no redundancy or 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?

The description is complete for the tool's complexity: it covers what the tool does, how to use each parameter, what happens after the call, and what errors are rejected. It even addresses edge cases like row reordering and template coordinates. No output schema exists, but the description sufficiently indicates the effects.

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

Parameters5/5

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

With schema coverage at 60%, the description adds substantial meaning to the parameters. It gives concrete examples for value_formula (e.g., multiplication, division by a named row), explains the #FIELD, #KEY, #PLACEHOLDER placeholders, and clarifies that passing null clears a rule while omitting leaves it unchanged—details not fully covered in the schema.

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?

The description opens with "Attach declarative rules to a field," a specific verb+resource that clearly states the tool's function. It distinguishes three rule kinds (value_formula, validation, editability) and explains how they relate, making it distinct from sibling tools like set_cells or eval_formula.

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?

The description explicitly explains when to use the tool, how to leave rules untouched vs. clear them, and provides detailed guidance on placeholders, including when to use the two-argument #FIELD for cross-row references and why BLOCKREF is forbidden. It also notes that running totals have no rule form and directs users to write those as ordinary cells, giving clear exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/logisky/logisheets-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server