Skip to main content
Glama
KitchenSink4AI

io.github.nometalalchemist/kitchensink4xl

get_grid_view

Read-only

View a sheet or range as a compact markdown table with A1 coordinates, formula and merged-cell markers, dimensions, and hazard summary, avoiding per-cell JSON dumps. Use the returned anchor to target edits to the shown region.

Instructions

A compact, token-efficient projection of a sheet or range: the true used range, a markdown table with A1 addressing (column letters across the top, row numbers down the side), formula and merged-cell markers, dimensions, and the hazard summary, so an agent can see the grid without a per-cell JSON dump.

location defaults to the sheet's used range. values='cached' shows last calculated values with formula cells marked (the florin character U+0192 marks a formula with no cached value); 'formula' shows the formula strings. The view paginates with max_rows and max_cols (caps 200 and 100) and reports truncated flags so the caller knows when to page. formula_cells maps addresses to their formula strings; merged ranges intersecting the view are listed. The result's anchor is a token for the shown rectangle: {"anchor": token} addresses it in any positional tool, refusing STALE_ANCHOR if the region changed since this view; cells inside stay plain A1. Read-only; works while the file is open in Excel. Pair it with apply_edits to edit what you see.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
sheetNo
valuesNocached
locationNo
max_colsNo
max_rowsNo

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 / location / anyOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "object"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedInput schema / properties / location / title
      Removed value: -"Location"
  3. First observedv1.0.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses pagination caps (200 and 100), truncated flags, the U+0192 marker for formulas with no cached value, anchor-token behavior with STALE_ANCHOR, and compatibility with files open in Excel. These are meaningful behavioral details not present in annotations or schema.

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 dense but front-loaded: the first sentence states the purpose and output shape, and subsequent sentences expand only on behaviors an agent must know. There is no filler and no repetition of structured schema information.

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?

For a read-only view tool with no output schema, the description explains the output shape, pagination, value modes, markers, anchor semantics, and a natural follow-up tool. An agent has enough information to invoke it correctly and interpret the result.

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?

With 0% schema description coverage, the description carries the burden and explains location defaulting to the used range, values='cached' versus 'formula' behavior, and max_rows/max_cols caps. However, path and sheet parameters are left implicit, so it does not fully compensate for the absence of schema descriptions.

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 names a specific operation—a compact grid-view projection of a sheet or range—and enumerates exactly what is returned: used range, markdown table with A1 addressing, formula and merged-cell markers, dimensions, and hazard summary. It also contrasts itself with a per-cell JSON dump, making its niche clear among read-oriented siblings.

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?

It is clearly positioned as the way to 'see the grid without a per-cell JSON dump,' and it explicitly warns that it is read-only, which rules out edit use cases. The pairing instruction with apply_edits gives a concrete alternative workflow, though it does not explicitly name other read tools to avoid.

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