Skip to main content
Glama
SheetForge MCP

SheetForge MCP

by iHeldan

quick_read

Read-only

Reads a compact table from a specified worksheet or the first sheet, returning array rows or object records with optional schema hints.

Instructions

Read a compact table from an explicit sheet or the first workbook sheet.

Can return either array rows or object-shaped records, plus optional schema
hints inferred from the returned rows.
sheet_name is a worksheet tab, NOT a native table name. For named tables use
read_excel_table(table_name=...); list_tables verifies the containing worksheet.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "filepath": "<filepath>"
    },
    "name": "quick_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
end_colNo
filepathYesReuse supplied server path; NEVER prepend client cwd. Rooted: relative OK; unrooted stdio: absolute, ask if missing.
max_rowsNo
row_modeNoarrays
start_colNoA
start_rowNo
header_rowNo
sheet_nameNo
infer_schemaNo
include_headersNo
read_boundary_modeNodefault

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.14.0
    • addedInput schema / properties / filepath / description
      Added value: +"Reuse supplied server path; NEVER prepend client cwd. Rooted: relative OK; unrooted stdio: absolute, ask if missing."
  2. Changed1 schema field changedv0.9.0
    • addedInput schema / properties / read_boundary_mode
      Added value: +{
      +  "default": "default",
      +  "title": "Read Boundary Mode",
      +  "type": "string"
      +}
  3. First observedv0.8.0

TDQS

A3.6/5.0
Behavior4/5

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

readOnlyHint=true already covers the safety profile, so the description's added value is the return-shape disclosure: array rows vs object-shaped records, plus optional inferred schema hints. That is meaningful context for a tool with no output schema. It does not mention error behavior, row-limit defaults, or how read_boundary_mode affects results.

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?

Front-loaded with the core capability in the first sentence, then the return-shape note, then the disambiguation caveat. Three tight blocks with no filler, though the parenthetical tool-call syntax in the final sentence is slightly informal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output side is adequately covered and the sheet-vs-table distinction is handled, but for an 11-parameter read tool with near-zero schema descriptions and no output schema, the range/header/limit parameters that determine what data actually comes back go unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 9% (only filepath is documented), so the description must compensate for 11 parameters, and it only clarifies sheet_name, row_mode's two output flavors, and infer_schema. start_col, end_col, start_row, header_row, max_rows, include_headers, and read_boundary_mode are left entirely unexplained in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: read a compact table from an explicit sheet or the first workbook sheet. It clearly distinguishes itself from read_excel_table by name, but does not distinguish itself from the other read siblings such as read_data_from_excel or read_excel_as_table, which an agent would also need to choose between.

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?

Explicitly routes named-table reads to read_excel_table(table_name=...) and notes list_tables verifies the containing worksheet, which is real when-to-use guidance. It also clears up an ambiguity (sheet_name is a worksheet tab, not a native table name). It lacks any when-not guidance relative to the other plain-read siblings.

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