Skip to main content
Glama
sheetrender

@sheetrender/mcp

Official

Create a dataset from JSON rows

create_dataset

Turn JSON rows into a dataset for batch PDF rendering, returning the dataset ID and column keys for template placeholders.

Instructions

SheetRender turns HTML templates plus spreadsheet rows into rendered PDFs. This tool turns rows you already hold — as JSON — into a dataset a batch job can render, and returns the dataset id plus the column keys.

This is the normal way to start a batch: the user asks for "an invoice for each of these clients" or "a letter per employee", you assemble the rows, and this uploads them. Use upload_dataset instead when the data is already a file on disk, and list_datasets when the user is referring to a dataset that already exists.

rows is a flat array of flat objects, one per document: [{"client": "Acme", "total": 42}, {"client": "Globex", "total": 17}]. The header is the union of every row's keys in first-seen order, so rows need not agree on their keys — a missing one is a blank cell, not a shifted row. Values must be strings, numbers, booleans or null; nested objects and arrays are rejected, so flatten or stringify them first. So are NaN, Infinity and whole numbers past 2^53 (send those as strings to keep them exact).

The dataset is attached to the template's project, which means every template in that project can render it and it stays available to later jobs.

Limits: 50,000 rows and 500,000 cells (rows x columns) per call. The row cap applies to JSON rows only — a bigger sheet can still go through upload_dataset as a file, which is bounded by size and cells rather than rows. Creating a dataset is free; only rendering counts against the account's plan.

Returns the dataset id and, for each column, the sanitized key. That key — not the original header — is what the template's placeholders, filename_template and group_by address, so read it off this result rather than guessing from the header text.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoOptional label for the dataset, used as its stored filename so the user recognises it later, e.g. "march-invoices".
rowsYesOne flat object per document. Keys become spreadsheet columns; values must be scalars (string, number, boolean or null).
template_idYesTemplate id from list_templates. The dataset lands in that template's project.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.4

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so richly: it discloses the flat-array/flat-object shape requirement, union-of-keys header semantics with missing keys becoming blanks, scalar-only value rules, rejection of NaN/Infinity/values past 2^53, the 50,000-row and 500,000-cell caps, that creation is free (only rendering is billed), and that the dataset is attached to the template's project and reusable by later jobs.

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 action, then constraints, then limits, then return semantics in a logical order. It is on the long side and the opening 'SheetRender turns HTML templates...' line is arguably ambient context, but every paragraph earns its place by resolving a real ambiguity.

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

Completeness5/5

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

There is no output schema, and the description compensates by stating what is returned (dataset id plus per-column sanitized keys) and warning that the sanitized key is what the template must reference. Combined with the limits, cost model, and placement rules, an agent has everything needed to call this correctly.

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 description coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the union-of-keys header derivation, the exact-number caveat (send large integers as strings), and that the returned sanitized `key` — not the original header — is what placeholders, filename_template and group_by address. That is meaningful semantics the schema does not carry.

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?

States a specific verb+resource ('turns rows ... into a dataset') and immediately distinguishes itself from siblings by naming upload_dataset and list_datasets with the conditions that select them. An agent can tell exactly what this does without opening the schema.

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

Usage Guidelines5/5

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

Explicit when-to-use ('the normal way to start a batch', with the user-intent example 'an invoice for each of these clients'), plus explicit when-not with named alternatives: upload_dataset for data already on disk, list_datasets for an existing dataset. Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.