Skip to main content
Glama
SheetForge MCP

SheetForge MCP

by iHeldan

describe_sheet_layout

Read-only

Summarizes a worksheet’s structural layout to help agents plan safe dashboard-style edits and avoid disrupting existing content.

Instructions

Return a structural worksheet layout summary for safe dashboard-style edits.

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>",
      "sheet_name": "<sheet_name>"
    },
    "name": "describe_sheet_layout"
  }
}

Input Schema

NameRequiredDescriptionDefault
filepathYesReuse supplied server path; NEVER prepend client cwd. Rooted: relative OK; unrooted stdio: absolute, ask if missing.
sheet_nameYes
sample_limitNo
free_canvas_colsNo
free_canvas_rowsNo
free_canvas_limitNo

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. First observedv0.8.0

TDQS

C2.4/5.0
Behavior2/5

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

The readOnlyHint annotation already tells the agent this is a safe read, and the description's "safe" adds nothing beyond that. It does not disclose what the summary contains, how the free-canvas sampling behaves, or any limits, so almost no behavioral context is added on top of structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

A single short sentence that is front-loaded and wastes no words, but its brevity is under-specification rather than efficiency. There is room to spend words on the return shape and parameters without bloat.

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

Completeness2/5

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

Six parameters, no output schema, and 17% schema coverage mean the description has to explain both inputs and what the layout summary reports. It does neither, leaving the agent unable to predict the response or the effect of the free-canvas and sample settings.

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

Parameters1/5

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

Schema coverage is 17% – only filepath is documented. Five parameters (sheet_name, sample_limit, free_canvas_cols, free_canvas_rows, free_canvas_limit) have no meaning given anywhere, and the description supplies none of the missing semantics. With low coverage the description carries the burden and fails entirely.

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

Purpose3/5

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

"Return a structural worksheet layout summary" states a verb and resource, but "structural layout summary" is opaque about what is actually returned (dimensions? merged cells? occupied regions?). It also fails to differentiate from nearby siblings like describe_dataset, get_workbook_metadata, or inspect_workbook_contract, which an agent could plausibly pick instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"for safe dashboard-style edits" implies the workflow (inspect before laying out a dashboard), which is genuine but indirect usage guidance. There are no explicit when-not conditions and no named alternatives, so the agent must infer the pre-flight positioning itself.

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