Skip to main content
Glama
KitchenSink4AI

io.github.nometalalchemist/kitchensink4xl

by KitchenSink4AI
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

get_table

Read-only

Retrieve an Excel table's data by name, returning column headers and row data without header or totals. Select cached or formula values, project columns, and page through large tables.

Instructions

Read a table's data by its name (case-insensitive). columns projects a subset; values is cached | formula | both (the honest calc story); records true returns row objects keyed by column name. Returns the table ref, the column names, and the data rows without the header or totals row; filter or page big tables with query_range and a {table} location. Advanced table ops (columns, totals, resize, banding): manage_table (design pack). Read-only; nothing is written.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
pathYes
valuesNocached
columnsNoTable column names to project.
recordsNo

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
    • changedInput schema / properties / columns / anyOf
      Previous value: -[
-  {
-    "items": {},
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / columns / description
      Added value: +"Table column names to project."
  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?

readOnlyHint=true is independently reinforced by 'Read-only; nothing is written,' and the description adds substantial behavior beyond the annotation: case-insensitive matching, the cached/formula/both semantics ('the honest calc story'), and the disclosure that returned rows exclude the header and totals row. No contradiction 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.

Conciseness4/5

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

One dense paragraph that front-loads the core purpose and packs each clause with distinct information: parameter semantics, return shape, sibling routing, and safety. Every sentence earns its place; the quirky parenthetical 'the honest calc story' and the trailing 'Read-only' reaffirmation are minor stylistic noise rather than waste.

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?

With no output schema, the description carries the return-value burden and meets it (table ref, column names, rows, header/totals exclusions), and the low schema coverage is compensated in prose. Remaining gaps are error behavior for missing tables and the precise shape of the table ref/location identifier.

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 coverage is only 20% (only columns has a schema description), but the description decodes values ('cached | formula | both'), columns ('projects a subset'), records ('row objects keyed by column name'), and name (case-insensitive). Only the required path parameter is left implicit, inferable from the '{table} location' routing remark.

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?

Opens with a specific verb+resource ('Read a table's data by its name') and adds a distinguishing qualifier (case-insensitive). The return-shape sentence — 'table ref, column names, data rows without the header or totals row' — makes it unambiguous that this reads whole table data, separating it from location-based siblings like read_range, get_grid_view, and get_cells.

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?

Explicitly routes big-table filtering/paging to query_range with a {table} location, and advanced table ops (columns, totals, resize, banding) to manage_table. The by-name scoping implicitly distinguishes it from location-based reads, giving an agent clear routing conditions without opening sibling schemas.

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