Skip to main content
Glama
KitchenSink4AI

io.github.nometalalchemist/kitchensink4xl

by KitchenSink4AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get Table

get_table
Read-only

Read an Excel table by name to retrieve its column names and data rows, with options to select specific columns, choose cached or formula values, and return records as row objects.

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.3/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true, and the description reinforces it with 'Read-only; nothing is written.' It also adds the behavior of excluding the header/totals row, which is not in annotations, and explains the 'values' caching semantics, going beyond what annotations provide.

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 dense and packed with information in a few sentences, but it's slightly long and could be better structured with clearer separation of concepts. However, it doesn't waste words and front-loads the purpose.

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 moderate complexity (5 params, output schema absent), the description covers return values, parameter behavior, and read-only nature. It also hints at performance concerns for large tables, which is valuable for correct invocation. Minor gaps like pagination details are handled by referencing query_range.

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%, so the description compensates by explaining the key parameters: 'columns' for projection, 'values' for caching modes, and 'records' for row object formatting. Although it doesn't detail 'path' and 'name', they are self-evident, and the description does add meaning to the less obvious ones.

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 reads table data by name, specifies case-insensitivity, and describes the returned elements (table ref, column names, data rows). It distinguishes itself from sibling tools like query_range and manage_table by noting that advanced operations are handled elsewhere.

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 provides usage context, such as using query_range for filtering/paging big tables and manage_table for advanced ops, but doesn't explicitly list when not to use this tool versus read_range or get_cells. However, the mention of alternatives gives clear context for distinct use cases.

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