Skip to main content
Glama
SheetForge MCP

SheetForge MCP

by iHeldan

run_workbook_recipe

Destructive

Preview or commit a reusable JSON recipe to group, filter, and aggregate workbook data into a reserved output range, with token and hash checks for safe writes.

Instructions

Preview or commit a reusable JSON recipe without echoing intermediate rows.

Recipe v1 requires version=1, source={table_name, optional sheet_name},
group_by=[exact header names], metrics=[{op, field, as}], and
output={sheet_name, range_ref, optional allow_overwrite=false}.
Optional filters use query_table operators; optional checks support unique_key
(fields), row_count (min/max), and sum_matches (source_field/output_field).
count metrics omit field. Other metrics: sum, avg, min, max, count_non_null,
count_distinct. Only literal finite JSON cells in referenced fields are supported.
Optional workbook_contract enforces Contract v1: source selectors must match,
ALL Recipe input references must use contract fields[].name, NEVER physical
fields[].headers. Copy names from inspection.recipe_input_fields (binding keys).
Example: net bound to NetSales -> metrics=[{op:"sum",field:"net",as:"Revenue"}];
currency bound to Currency -> group_by=["currency"]. The as label stays Revenue.
This also applies to filters.field, unique_key.fields and sum_matches.source_field.
Contract field errors return bounded details.examples with Recipe JSON-pointer
paths and exact replace_with names where known: fix the Recipe references only,
keep workbook_contract unchanged, then make a NEW preview before commit.
Contract filters are mandatory
AND predicates. All contract rows are checked before filtering and again on
the saved workbook. Repeat the identical contract on commit; changed contracts
invalidate recipe tokens. Declared meanings are not verified business truth.

Output is one reserved rectangle in the same workbook, fully replaced including
blank padding. Occupied output requires allow_overwrite=true; table/merge overlap
is rejected. Preview first, then commit the unchanged recipe with recipe_token
and expected_workbook_sha256 from preview. A verified snapshot is always enabled.
Limits: 50,000 source cells, 64 source columns, 10,000 output cells; sample_limit 1-10.

Input Schema

NameRequiredDescriptionDefault
modeNopreview
recipeYes
filepathYesReuse supplied server path; NEVER prepend client cwd. Rooted: relative OK; unrooted stdio: absolute, ask if missing.
recipe_tokenNo
sample_limitNo
workbook_contractNo
expected_workbook_sha256No

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.14.0

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only carry destructiveHint=true; the description fills in extensive behavior beyond that: the output rectangle is 'fully replaced including blank padding,' occupied output needs allow_overwrite=true, table/merge overlap is rejected, contract changes invalidate recipe tokens, a snapshot is always enabled, and 'declared meanings are not verified business truth.' Hard limits (50k source cells, 64 columns, 10k output cells, sample_limit 1-10) are also disclosed.

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?

The purpose is front-loaded, but the body is a dense unfragmented block of run-on sentences and parenthetical asides. Most content earns its place given the recipe DSL's complexity, but bullet-less prose with rapid topic shifts reduces scannability.

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?

For a nested-object tool with no output schema, it covers the critical call-path details: recipe construction, contract enforcement, token/sha handoff, overwrite semantics, error shape (details.examples with JSON-pointer paths), and limits. It doesn't describe what a preview actually returns structurally (only that sample_limit controls sampling), leaving a small gap.

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 14% (only filepath is documented), so the description must compensate, and it largely does: it spells out the v1 recipe shape (version, source, group_by, metrics with op/field/as, output, filters, checks) and explains recipe_token and expected_workbook_sha256 as coming from preview, plus sample_limit 1-10. It leaves the mode enum's default and full meaning implicit and only references filters/checks as 'query_table operators' without detail.

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?

The first sentence states a specific verb pair (preview/commit) and a specific resource (a reusable JSON recipe that writes to a reserved output rectangle in a workbook). The 'without echoing intermediate rows' clause adds a distinguishing trait. It doesn't explicitly say how it differs from sibling aggregate_table or query_table, keeping it at 4.

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?

Gives an explicit workflow: 'Preview first, then commit the unchanged recipe with recipe_token and expected_workbook_sha256 from preview.' Also prescribes the error-recovery sequence ('fix the Recipe references only, keep workbook_contract unchanged, then make a NEW preview'). However, it never says when to reach for this tool versus aggregate_table/query_table, so no explicit alternative routing.

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