Skip to main content
Glama
SheetForge MCP

SheetForge MCP

by iHeldan

format_range

Destructive

Applies font, fill, alignment, borders, number formats, and conditional formatting to a specified cell range in an Excel sheet, with optional dry-run preview.

Instructions

Apply formatting to a range of cells. Colors accept RRGGBB, #RRGGBB, AARRGGBB, or #AARRGGBB.

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>",
      "start_cell": "<start_cell>"
    },
    "name": "format_range"
  }
}

Input Schema

NameRequiredDescriptionDefault
boldNo
italicNo
dry_runNo
bg_colorNo
end_cellNo
filepathYesReuse supplied server path; NEVER prepend client cwd. Rooted: relative OK; unrooted stdio: absolute, ask if missing.
alignmentNo
font_sizeNo
underlineNo
wrap_textNo
font_colorNo
protectionNo
sheet_nameYes
start_cellYes
merge_cellsNo
border_colorNo
border_styleNo
number_formatNo
include_changesNo
conditional_formatNo

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

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

Annotations declare destructiveHint=true, so the safety profile is partly covered. But the description never warns that applying formatting overwrites existing cell formatting, never explains what `dry_run` previews, and never mentions whether `include_changes` returns a diff — all material for a 20-parameter mutation tool. The color-syntax note is useful but is parameter-level detail, not behavioral disclosure.

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?

Two sentences, zero filler, action front-loaded before the format detail. The efficiency is good, though the brevity edges into under-specification for a tool this large.

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?

A 20-parameter destructive mutation with 5% schema coverage, no output schema, and several nested-object params (protection, conditional_format) is not adequately explained by two sentences. An agent could invoke it, but would be guessing on most of the surface area and on the dry-run/change-reporting workflow.

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 5% across 20 parameters, so the description carries nearly the full burden and mostly fails it. It clarifies color string formats (RRGGBB / #RRGGBB / AARRGGBB / #AARRGGBB) for bg_color, font_color, and border_color, but leaves alignment, number_format, border_style, protection, conditional_format, merge_cells, dry_run, and include_changes entirely unexplained.

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 ("Apply formatting to a range of cells") that an agent can act on immediately. However, it does nothing to distinguish this from the near-identical sibling `format_ranges`, so an agent has no basis for choosing between the singular and plural variants.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites, and no mention of when to prefer `format_ranges`, `copy_range`, or `read_range_formatting` instead. The `dry_run` parameter strongly implies a preview workflow but the description never says to preview before applying, which is exactly the kind of guidance a destructive tool needs.

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