Skip to main content
Glama
KitchenSink4AI

io.github.nometalalchemist/kitchensink4xl

Modify Grid Structure

modify_grid_structure
Destructive

Insert or delete rows and columns across Excel sheets while automatically rewriting every formula, name, and reference to keep the workbook 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.3/5.0
Behavior5/5

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

Annotations only declare destructiveHint=true and readOnlyHint=false. The description goes far beyond that: it details reference-rewrite scope, #REF! behavior, refusal on loss unless allow_loss, backup rotation, atomic verified save, and refusal while open in Excel. This is rich behavioral disclosure that fully covers the tool's side effects.

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 substantive value given the tool's complexity. It front-loads the core purpose and then enumerates behaviors and parameters in a logical order. It is dense but not bloated; the length is justified by the intricate rewrite and safety mechanics.

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?

For a tool with 8 parameters, no output schema, and destructive behavior, the description covers most critical aspects: reference rewriting, #REF! reporting, refusal conditions, backup/restore, and return counts. Missing details like the exact meaning of 'verify_com' and the full behavior of 'sheet' are minor gaps, but given the complexity, the description is largely complete.

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 only 13% (only 'at' has a description). The description adds meaning for 'action' (lists allowed values), 'at' (explains multiple formats), and 'count' (edits that many at once). It also touches on 'backup' and 'allow_loss' behavior. However, it leaves 'path', 'sheet', and 'verify_com' unexplained, and 'path'/'sheet' are essential for targeting the workbook. It compensates partially but not fully.

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 clearly states the tool inserts or deletes rows/columns and rewrites all references to keep the workbook coherent. It is specific about the resource (grid structure) and the verb (insert/delete), and the detail on reference rewriting distinguishes it from siblings like apply_edits.

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 provides clear context on when this tool is appropriate (structural edits with reference rewriting) and mentions refusal conditions (hazardous workbook, open in Excel). However, it does not explicitly name alternative tools or state when not to use it, so it lacks explicit exclusions.

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