Skip to main content
Glama
KitchenSink4AI

io.github.nometalalchemist/kitchensink4xl

modify_grid_structure

Insert or delete rows or columns while automatically rewriting every formula, defined name, data validation, conditional format, table reference, and merged range so the workbook remains coherent.

Instructions

Insert or delete rows or columns at a position and REWRITE EVERY REFERENCE so the workbook stays coherent: formulas on every sheet (cross-sheet refs included), defined names, data validations, conditional-format ranges, table refs, and merged ranges all shift with the edit. action is insert_rows, delete_rows, insert_cols, or delete_cols; at is the 1-based row number or column letter where the edit starts (a cell like 'B7' or a location object also works, using its top-left); count edits that many at once.

Whole-column spans like =SUM(B:B) and whole-row spans like $1:$2 shift on their own axis; an edit on the other axis leaves them alone (Excel's behavior). A reference wholly inside a deleted band becomes #REF! and the new-#REF! count is reported, never hidden; an insert that would push value-bearing cells off the grid edge refuses. Returns per-kind rewrite counts. A hazardous workbook refuses unless allow_loss is true. Auto-backup: prev/anchor slots in .ks4xl-backups (backup=false skips rotation); atomic verified save, restored on failed verify; the prev slot is the undo for a delete. Refuses while open in Excel.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atYesWhere the insert or delete starts: a 1-based row number (5), a column letter ('B'), an A1 cell ('B7', whose row or column is used), or a location object.
pathYes
countNo
sheetNo
actionYes
backupNo
allow_lossNo
verify_comNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "type": "object"
      -}New value: +null
  2. Changed2 schema fields changedv1.1.0
    • addedInput schema / properties / at / anyOf
      Added value: +[
      +  {
      +    "minimum": 1,
      +    "type": "integer"
      +  },
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "object"
      +  }
      +]
    • addedInput schema / properties / at / description
      Added value: +"Where the insert or delete starts: a 1-based row number (5), a column letter ('B'), an A1 cell ('B7', whose row or column is used), or a location object."
  3. First observedv1.0.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false, so the description carries the full burden. It discloses extensive behavior: reference rewriting across sheets, defined names, validations, conditional formats, tables, and merges; axis-specific handling of whole-column/row spans; #REF! results and their reporting; refusal conditions; per-kind rewrite counts; auto-backup rotation; atomic verified save with restoration; and undo semantics via the prev slot. This is exceptional transparency.

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?

The description is long, but every sentence adds meaningful behavioral or parameter information. It is front-loaded with the core purpose and reference-rewriting guarantee, followed by parameter and safety details. It could be organized into bullet points for readability, but there is no filler or redundancy.

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?

Given the tool's complexity, minimal schema descriptions, no output schema, and only readOnlyHint=false, the description covers most of what an agent needs: exact actions, positional inputs, refusal conditions, return type, backup, and save verification. Gaps remain for the sheet and verify_com parameters, which are not mentioned at all, and the exact output structure is only summarized.

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 description coverage is only 13%, and the description compensates well: it explains action values, the various forms of at (row number, column letter, A1 cell, location object), count semantics, backup skipping, and allow_loss behavior. It does not explain sheet, verify_com, or path, but the key parameters are substantially enriched beyond the bare 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 a specific verb and resource: 'Insert or delete rows or columns at a position' and immediately adds the defining behavior 'REWRITE EVERY REFERENCE so the workbook stays coherent.' This clearly distinguishes it from sibling tools like apply_edits or set_dimensions by emphasizing the global reference-rewriting effect.

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?

The description gives clear context for when the tool applies: inserting/deleting rows or columns with actions enumerated, and it explicitly states when the tool refuses (hazardous workbook without allow_loss, workbook open in Excel, insert pushing cells off grid). It does not explicitly name alternative tools or when-not conditions relative to siblings, but the operation-specific context is strong.

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