Skip to main content
Glama
sheetrender

@sheetrender/mcp

Official

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
SHEETRENDER_API_KEYYesYour SheetRender API key (sr_live_...). Create one at sheetrender.com under Settings -> API keys.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
render_pdfA

SheetRender turns HTML templates plus spreadsheet rows into rendered PDFs. This tool renders a single PDF from HTML you supply and returns the path to the saved file.

Use it for one-off documents — an invoice, a report, a certificate — where you are writing the markup yourself. Use render_template instead when the user already has a saved template.

html must be a complete HTML document (, , ) with all CSS inline in a tag: external stylesheets, fonts and scripts are not fetched. Use @page and mm/cm units for print layout.

data keys become Jinja template variables, so passing {"total": "42.00"} lets the HTML say {{ total }}. Jinja loops and conditionals work too. Omit data if the HTML has no placeholders.

Two server limits to plan for: HTML over 2 MB is rejected, measured both on what you send and on the result after data is substituted in, so keep large tables paginated rather than emitting one enormous document; and accounts on the free plan get a "Made with SheetRender" footer added to every PDF, which is expected, not a bug — mention it if the user seems surprised.

Returns the temp-file path and size; PDFs under 512 KB are also attached inline.

list_templatesA

SheetRender turns HTML templates plus spreadsheet rows into rendered PDFs. This tool lists the templates saved in the user's account, with the id each one needs.

Call it first whenever the user refers to a template by name ("render the invoice template") so you can map that name to an id — every other tool here takes a template_id, including create_dataset and list_datasets. Takes no arguments.

design_templateA

Design a saved template from exactly one of dataset_id, inline rows, or data_base64 with data_filename (CSV or XLSX, up to 10 MB), and an example, brief, or style_id. Use an example alone, or a brief with optional style_id. Examples accept PDF, PNG, JPG, WebP or DOCX as base64 with a filename. Local data_path can supply the data; example_path can supply the example. Waits up to 3 minutes; returns the design status, template id, mapping and preview URL.

get_designA

Get a design's status and, when complete, its template id, name, mapping and preview URL.

render_templateA

SheetRender turns HTML templates plus spreadsheet rows into rendered PDFs. This tool renders one PDF from a template already saved in the user's account and returns the path to the saved file.

Use it when the user wants a document in their existing design. Get template_id from list_templates. Use render_pdf instead when you are writing the HTML yourself.

data supplies one row's worth of values: each key becomes a Jinja variable in the template's HTML. To render a PDF for every row of a spreadsheet, load the rows with create_dataset or upload_dataset and run create_batch_job rather than calling this repeatedly.

Omit page_settings to keep the template's own saved page setup — passing it overrides that for this render only.

Free-plan accounts get a "Made with SheetRender" footer on the PDF, same as render_pdf — expected, not a bug.

Returns the temp-file path and size; PDFs under 512 KB are also attached inline.

create_datasetA

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.

upload_datasetA

SheetRender turns HTML templates plus spreadsheet rows into rendered PDFs. This tool uploads a local .csv or .xlsx file as a dataset a batch job can render, and returns the dataset id plus the column keys.

Use it when the user points at a file they already have — an export, a spreadsheet they attached, something you just wrote to disk. Use create_dataset instead when you are holding the rows as JSON: it avoids writing a file only to read it straight back.

file_path is a path on the machine running this MCP server, which is the user's machine, not SheetRender's. The first row must be the header. Other spreadsheet formats (.xls, .ods, .numbers) and .pdf are not parsed — convert to .csv or .xlsx first.

Limits: 20 MB per file and 500,000 cells; larger data has to be split across several datasets and jobs. Uploading is free; only rendering counts against the account's plan.

Returns the dataset id and each column's sanitized key — the name the template's placeholders, filename_template and group_by use, which is often not the header text verbatim ("Invoice No" becomes invoice_no).

list_datasetsA

SheetRender turns HTML templates plus spreadsheet rows into rendered PDFs. This tool lists the datasets a batch job can render with a given template — everything in that template's project, newest first — with each one's id, row count and column keys.

Call it when the user refers to data they have already loaded ("use the customer list I uploaded") so you can find its id, or to re-run a batch over an existing dataset instead of creating a duplicate. When there is nothing suitable, create one with create_dataset or upload_dataset.

It is also the quickest way to see a dataset's sanitized column keys before writing a filename_template or choosing group_by.

create_batch_jobA

SheetRender turns HTML templates plus spreadsheet rows into rendered PDFs. This tool queues a batch job that renders one PDF per row of a dataset, and returns the job id.

Use it when the user wants many documents at once — "an invoice for every row", "one letter per employee" — rather than calling render_template in a loop.

The full sequence, all of it available here:

  1. list_templates — the user's designs, and the template_id for the rest.

  2. create_dataset (rows you hold as JSON) or upload_dataset (a local .csv/.xlsx) — returns the dataset_id. list_datasets finds one that already exists.

  3. create_batch_job — this tool, returning a job id.

  4. get_job — poll until the status is finished; it then lists the document ids.

  5. get_document — download any of those PDFs.

The dataset must belong to the same template's project, which is where create_dataset or upload_dataset put it. Rendering happens in the background, so the job id comes back long before the PDFs do.

filename_template and group_by name columns by their sanitized key, which create_dataset, upload_dataset and list_datasets all report — it is often not the header text verbatim ("Invoice No" becomes invoice_no). Both are saved onto the template/project, so they change the defaults for later runs, not just this one. Only pass them when the user asked to change how output is named or grouped.

get_jobA

SheetRender turns HTML templates plus spreadsheet rows into rendered PDFs. This tool reports the progress of a batch job started by create_batch_job.

Returns the status, rows done/failed, and — once the job reaches a finished state ("succeeded", "partial", "failed" or "cancelled") — the id and filename of every rendered document. The document list is empty while the job is still in "queued", "retry_queued" or "running", so poll again after a short wait rather than assuming zero documents.

Pass those document ids to get_document to download the individual PDFs.

get_documentA

SheetRender turns HTML templates plus spreadsheet rows into rendered PDFs. This tool downloads one PDF produced by a batch job and returns the path to the saved file.

document_id comes from get_job on a finished batch — that is the only place these ids appear, so call get_job first and take an id from its document list. A document id is not a template id or a job id.

Use it to fetch a specific output the user asked about, or to spot-check a batch. Fetching every document of a large batch one at a time is slow; point the user at the SheetRender web app for the merged PDF or ZIP instead.

Returns the temp-file path and size; PDFs under 512 KB are also attached inline.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.3/5.0

Scored across 11 tools

Disambiguation4/5

Most tools are clearly distinct: render_pdf vs render_template (write HTML yourself vs use saved template), create_dataset vs upload_dataset (JSON rows vs local file), and get_job vs get_document (job status vs PDF download) are all explicitly cross-referenced. The only mild overlap is between get_design/template design tools and the job/polling tools, but descriptions draw the lines well.

Naming Consistency5/5

Every tool follows a consistent snake_case verb_noun pattern: get_design, render_pdf, list_templates, design_template, get_job, render_template, create_dataset, upload_dataset, list_datasets, create_batch_job, get_document. No mixed conventions or vague verbs.

Tool Count5/5

11 tools is well-scoped for a template/PDF rendering service, covering the full workflow (list, render, design, dataset creation, batch jobs, document retrieval) without redundancy or bloat.

Completeness4/5

The surface covers the core lifecycle: template discovery, single and batch rendering, dataset creation/upload/listing, job polling, and document download. Minor gaps exist — no delete/update operations for templates or datasets, and no explicit cancel_job tool despite job statuses mentioning 'cancelled' — but agents can work around these.

Maintenance

ActivityMaintained
ResponsivenessNo issues