Skip to main content
Glama
KitchenSink4AI

io.github.nometalalchemist/kitchensink4xl

by KitchenSink4AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get Grid View

get_grid_view
Read-only

Inspect an Excel sheet or range as a compact, token-efficient grid showing A1 addresses, formula and merged-cell markers, pagination, and cached values, so you can see the data without a per-cell JSON dump.

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?

Rich behavioral detail beyond the readOnlyHint annotation: values='cached' vs 'formula', the florin character for uncached formula cells, pagination caps and truncation flags, merged-range listing, formula_cells mapping, stale-anchor behavior, and the fact that it works while the file is open in Excel. It also explicitly confirms read-only behavior, consistent with annotations.

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 densely informative, with the core purpose front-loaded and every sentence contributing operational value. The logical order moves from what the view is, to parameters, to output details, to usage with apply_edits, which makes it easy for an agent to parse.

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?

Given the tool's complexity and the absence of an output schema, the description is remarkably complete: it covers the markdown output, A1 addressing, formula markers, merged ranges, dimensions, hazard summary, pagination, truncation flags, anchor token semantics, and staleness behavior. The only minor omissions are path/sheet formats, but these do not undermine callability.

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 compensates substantially by explaining location defaults, values modes, and max_rows/max_cols caps. However, it does not explain the required 'path' parameter or the 'sheet' parameter semantics, so an agent still has to infer those from context.

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 precise statement: a compact, token-efficient projection of a sheet or range, and enumerates exactly what the view contains (used range, markdown table, A1 addressing, formula/merged-cell markers, dimensions, hazard summary). It clearly distinguishes this from a per-cell JSON dump and positions it against sibling tools like read_range and 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 gives clear usage context: use this to see the grid efficiently without a per-cell JSON dump, defaults to the sheet's used range, and pairs with apply_edits for editing. It does not explicitly name alternatives or state when not to use it, so it stops short of a full 5.

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