Tanod MCP server

pdfpeek: build an Excel workbook from JSON

build_xlsx_workbook

Idempotent

Convert JSON sheets and rows into a styled .xlsx workbook with typed columns for Excel reports or data exports.

Instructions

pdfpeek: Build a styled Excel workbook from JSON sheets, columns and rows. To read a workbook back use convert_excel_to_json; for slides use build_pptx_deck. Rows are arrays or objects; a column type (string, number, integer, date, datetime, boolean, currency, percent) sets the format. Strings are always stored as text, never as formulas. At most 20 sheets, 50,000 cells, 32,767 characters per cell; sheet names of at most 31 characters without [ ] : * ? / . Over a limit is a 422 (not charged). Typically under 1 s. Price: USD 0.005. No free tier. Docs: https://tanod.dev/learn/xlsx-build-api.html

Input Schema

TableJSON Schema

Name	Required	Description	Default
`output`	No	base64 (default): the file comes back inline as base64. url: the file is stored for 24 hours and the reply carries a download link (url, expires_at, bytes, content_type, sha256) instead of the base64, which keeps the file out of your context window.	base64
`sheets`	Yes	The sheets, in order: 1-20, each with a unique name, optional typed columns and rows (at most 50,000 cells in all).
`filename`	No	Name of the returned file (default workbook.xlsx; .xlsx is added when missing; only letters, digits, space, dot, dash and underscore are kept).

Output Schema

TableJSON Schema

Name	Required	Description
`file`	No
`rows`	No
`cells`	No
`error`	No	Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object.
`sheets`	No
`operation`	No
`output_bytes`	No
`sheet_summary`	No
`formula_like_strings`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 15, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already flag it as a non-destructive, idempotent, open-world writer, and the description adds substantial extra context beyond them: hard limits (20 sheets, 50,000 cells, 32,767 chars/cell, 31-char sheet names excluding [ ] : * ? / \), the 422-without-charge behavior on over-limit, 'strings stored as text never as formulas', typical latency, and pricing. That is unusually rich behavioral disclosure with no contradictions.

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 purpose and alternatives, then constraints, cost, and docs link. Some redundancy with the schema (repeating the full type list), but every sentence carries operational value such as limits, error semantics, and price.

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?

With an output schema present, return values need not be explained. The description covers limits, failure behavior, cost model, and alternatives, which is everything an agent needs to call this 3-param build tool correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents output, sheets, and filename. The description restates the rows-as-arrays-or-objects rule and the column type enum, adding little beyond what the schema provides; baseline 3 applies.

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 and resource: 'Build a styled Excel workbook from JSON sheets, columns and rows.' It also names the sibling it is not ('To read a workbook back use convert_excel_to_json; for slides use build_pptx_deck'), so an agent can distinguish it from the other pdfpeek build/convert tools immediately.

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?

Explicitly routes the agent to alternatives for the reverse direction (convert_excel_to_json) and adjacent output format (build_pptx_deck). No explicit 'when not to use' or prerequisite guidance, but the sibling routing gives clear selection context.

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

Deploy Server