What can you do with this server?

The Bilig WorkPaper server provides a headless spreadsheet runtime for programmatically reading, writing, and recalculating formula-driven workbooks via MCP tools. * Discover sheets (list_sheets): Retrieve all sheet names, dimensions, writable status, and the source JSON file path. * Read a range (read_range): Fetch calculated values and raw serialized content (including formulas) for an A1-style range. * Read a single cell (read_cell): Get a cell's calculated value, display text, formula, and raw serialized content. * Write to a cell (set_cell_contents): Set literal values or formulas, trigger automatic recalculation of all dependents, atomically persist the workbook, and receive a before/after/restored diff with integrity checks. * Get display value (get_cell_display_value): Retrieve the human-readable formatted string for a cell (e.g., currency formatting). * Validate formula syntax (validate_formula): Check a formula string for syntax errors before writing it to a cell. * Export the workbook (export_workpaper_document): Serialize the full workbook state to JSON for backup, persistence, or handoff.

Which integrations are available for this server?

Provides tools for integrating spreadsheet formula evaluation into LangChain agents, enabling agent tool-calling for workbook operations such as reading and writing cells. Enables serverless API routes that use headless spreadsheet formulas, with integration examples for Vercel AI SDK and serverless deployment.

Bilig WorkPaper

by proompteng

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Bilig

npm Node.js OpenSSF Scorecard License: MIT

Keep the workbook model. Run the rule in Node.

Bilig is a TypeScript-native, headless WorkPaper runtime for Node.js services, tests, and AI agents. Set inputs, recalculate formulas, read computed outputs, persist WorkPaper JSON, restore it, and verify the result—without driving Excel or a browser grid.

Docs · Quick start · TypeScript API · MCP · Examples · Discussions

NOTE

Bilig is a headless workbook runtime, not a visual spreadsheet app or a claim of full Excel compatibility. If an.xlsx file is your contract, start with the compatibility report.

Quick Start

Prove the published package before installing it:

npm exec --yes --package @bilig/workpaper@latest -- bilig-evaluate --door workpaper-service --json

The evaluator edits Inputs!B2, recalculates Summary!B2, saves the WorkPaper, restores it, and compares the restored value:

{
  "schemaVersion": "bilig-evaluator.v1",
  "door": "workpaper-service",
  "evidence": {
    "editedCell": "Inputs!B2",
    "dependentCell": "Summary!B2",
    "before": 24000,
    "after": 38400,
    "afterRestore": 38400
  },
  "verified": true
}

verified: true means the write, formula readback, JSON export, and restored readback all passed. It is stronger evidence than a successful write call.

Related MCP server: animus-document-engine

Use It From TypeScript

npm install @bilig/workpaper

import { buildA1WorkPaper } from "@bilig/workpaper";

const pricing = buildA1WorkPaper({
  Inputs: [
    ["Metric", "Value"],
    ["Units", 20],
    ["Price", 1200],
  ],
  Summary: [
    ["Metric", "Value"],
    ["Revenue", "=Inputs!B2*Inputs!B3"],
  ],
});

const proof = pricing.editAndReadback("Inputs!B2", 32, {
  readbackRange: "Summary!B2",
});

console.log(proof.afterReadback.displayValues[0]?.[0]); // 38400
console.log(proof.verified); // true

pricing.dispose();

For ordinary operations, use set(), setMany(), readMany(), display(), and saveJson(). Use editManyAndReadback() when multiple inputs must be committed and verified as one edit. The complete public API is documented in packages/workpaper/README.md.

The lifecycle is deliberately small:

inputs → formula recalculation → typed readback → JSON persistence → restore verification

Why Bilig

Capability	What it gives you
Workbook-shaped models	Sheets, A1 addresses, formulas, ranges, and named expressions without a spreadsheet UI.
Verified mutations	Before/after computed values plus persistence and restore checks.
Service-owned state	Portable WorkPaper JSON for routes, queues, tests, tools, and audit trails.
Agent-safe tools	Narrow read/write tools with exact cells, computed readback, and writable-sheet boundaries.
Explicit file boundaries	Separate XLSX import, export, risk inspection, and Excel-oracle workflows.

Use Bilig for pricing, quote approval, payouts, forecasts, validation rules, formula-backed workflows, and tests where a service or tool should own the model. Choose a spreadsheet application or hosted spreadsheet API when you need visual editing, collaboration, macros, interactive pivots or charts, or desktop fidelity.

Agents And MCP

Agents should first ask which system owns state, then run the smallest matching proof. For a tool host or MCP client:

npm exec --yes --package @bilig/workpaper@latest -- bilig-agent-start --json
npm exec --yes --package @bilig/workpaper@latest -- bilig-evaluate --door agent-mcp --json

The MCP evaluator proves tool discovery, mutation, recalculated readback, JSON export, disk persistence, process restart, and restored readback. For a local, writable WorkPaper:

npm exec --yes --package @bilig/workpaper@latest -- bilig-workpaper-mcp --workpaper ./pricing.workpaper.json --init-demo-workpaper --writable

Use that local stdio path for private or persistent project state. The hosted https://bilig.proompteng.ai/mcp endpoint is request-local and only intended for stateless connector discovery and smoke tests; do not send private workbook data to it.

The server exposes list_sheets, read_range, read_cell, set_cell_contents, set_cell_contents_and_readback, get_cell_display_value, export_workpaper_document, and validate_formula. It also publishes MCP resources and prompts so capable hosts can discover the workflow before editing cells.

Machine-readable entry points:

Need	Entry point
A compact routing card	`docs/agent-start.txt`
A concise model index	`docs/llms.txt`
Full agent documentation	`docs/llms-full.txt`
Installation context	`docs/llms-install.md`
Structured capabilities	`docs/agent.json`
Reusable skill	`skills/bilig-workpaper/SKILL.md`
Proof and host matrix	`docs/agent-adoption-kit.md`

The published package also carries AGENTS.md and SKILL.md, so an agent can discover the same proof contract from node_modules. Install or inspect the public skill with either source:

npx --yes skills@latest add https://bilig.proompteng.ai --list
npx --yes skills@latest add proompteng/bilig --skill bilig-workpaper --list

Use the agent rule chooser or the host handoff prompt. The repository includes CLAUDE.md, .claude/skills/bilig-workpaper/SKILL.md, .claude/commands/bilig-workpaper-proof.md, .cursor/rules/bilig-workpaper.mdc, .devin/rules/bilig-workpaper.md, .windsurf/rules/bilig-workpaper.md, .clinerules/bilig-workpaper.md, .continue/rules/bilig-workpaper.md, .zed/settings.json, opencode.jsonc, and .opencode/agents/bilig-workpaper.md.

Integration Recipes After The Proof

Run an evaluator first, then use the recipe owned by your host:

OpenAI Agents SDK: direct tools, MCPServerStdio, and MCPServerStreamableHttp.
OpenAI Responses API: function-call readback with explicit before/after evidence.
Vercel AI SDK: generateText() and streamText() tool loops.
Open WebUI: local or hosted MCP discovery.
n8n: the @bilig/n8n-nodes-workpaper community node.

Choose An Evaluation Path

Your state owner	Start here	Evidence to require
TypeScript application	`npm install @bilig/workpaper`	direct A1 API and focused application tests
Node service, route, queue, or test	`bilig-evaluate --door workpaper-service --json`	edit, recalculation, JSON export, restore, `verified: true`
MCP client or tool host	`bilig-evaluate --door agent-mcp --json`	discovery, readback, disk persistence, restart
Imported `.xlsx` is the contract	`workbook-compatibility-report workbook.xlsx --json`	unsupported formulas and workbook risk reasons for that file
Cached `.xlsx` values look stale	`xlsx-cache-doctor workbook.xlsx --json`	stale-cache diagnosis, recalculation, and readback for that file

The workbook-compatibility and xlsx-cache evaluator doors use bundled demo workbooks to smoke-test the published package; they do not inspect your file. Do not treat any evaluator as proof of desktop Excel parity.

Examples And Deeper Guides

Start with one maintained example, not the whole monorepo:

examples/headless-workpaper: pricing, invoice, budget, fulfillment, subscription, persistence, and agent examples.
examples/serverless-workpaper-api: quote approval through Hono, Next.js, and persistence adapters.
examples/xlsx-recalculation-node: import, recalculate, export, reimport, and verify an XLSX workbook.
examples/recalc-bridge-workflows: focused bridges for existing SheetJS, xlsx-populate, and ExcelJS workflows.

Useful decision guides:

pnpm --dir examples/headless-workpaper run agent:ai-sdk-generate-text
pnpm --dir examples/headless-workpaper run agent:ai-sdk-stream-text
pnpm --dir examples/headless-workpaper run agent:openai-responses
pnpm --dir examples/headless-workpaper run agent:mcp-xlsx-risk-preflight
pnpm --dir examples/serverless-workpaper-api run hono-route
pnpm --dir examples/serverless-workpaper-api run next-server-action
pnpm --dir examples/serverless-workpaper-api run next-server-action-formdata

The AI SDK generateText() smoke lives at ai-sdk-generate-text-tool-smoke.ts. The OpenAI example is documented in openai-responses-workpaper-tool-call.

For a reduced formula or import bug:

npm exec --yes --package @bilig/workpaper@latest -- bilig-formula-clinic ./reduced.xlsx --cells "Summary!B7,Inputs!B2"

XLSX And Excel Compatibility

Bilig can import and export workbook files, but cached formula values inside an .xlsx are diagnostics—not an accuracy oracle. Inspect the file before trusting it:

npm exec --yes --package @bilig/xlsx-formula-recalc@latest -- bilig-evaluate --door workbook-compatibility --json
npm exec --yes --package @bilig/xlsx-formula-recalc@latest -- workbook-compatibility-report workbook.xlsx --json
npm exec --yes --package @bilig/xlsx-formula-recalc@latest -- xlsx-cache-doctor workbook.xlsx --json

The first command is a package smoke test over a bundled demo. The next two inspect the named file. The compatibility report identifies unsupported functions, external links, macros, pivots, volatile formulas, and other risks; it does not certify Excel compatibility. When correctness matters, compare against a workbook freshly recalculated by Excel. See the compatibility limits and Excel oracle walkthrough.

Packages And Repository Map

Path	Role
`packages/workpaper`	Recommended `@bilig/workpaper` API, evaluators, AI SDK adapter, MCP server, and XLSX boundary.
`packages/headless`	Lower-level WorkPaper runtime and integration primitives.
`packages/xlsx-formula-recalc`	Real-file compatibility and stale-cache diagnostics.
`packages/formula`	Formula parser, binder, compiler, and evaluator.
`packages/core`	Workbook state, mutations, snapshots, and scheduling.
`apps/web`	Browser spreadsheet shell.
`apps/bilig`	Full-stack runtime, APIs, and static site host.

The public package requires Node.js >=22. Local monorepo development uses Node.js 24+, Bun, and pnpm@10.32.1.

Published releases include npm registry signatures and provenance attestations:

npm view @bilig/workpaper version dist.attestations dist.signatures --json
npm audit signatures

Development

Choose one long-running development server:

pnpm dev:web
pnpm dev:web-local

Install and validate the repository with:

pnpm install
pnpm build
pnpm lint
pnpm typecheck
pnpm test
pnpm run ci

Architecture lives in docs/architecture.md. Read CONTRIBUTING.md before opening a pull request; first-time contributors can start with the new contributor guide and starter issues. All participation follows the CODE_OF_CONDUCT.md.

Support And Security

Ask adoption and design questions in Discussions.
Follow versioned changes through GitHub Releases.
Report reproducible bugs through Issues; reduced workbooks can use the formula bug clinic and fixture form.
Read SUPPORT.md for the evidence that makes a report actionable.
Follow SECURITY.md for private vulnerability reporting. Never attach private workbook data, credentials, or tokens to a public issue.

If Bilig fits one of your services or agent workflows, star the repository to follow releases and help other Node developers find it. Tell us what proof or formula is still missing.

License

MIT

Available Tools

7 tools

export_workpaper_documentExport WorkPaper DocumentA

Read-onlyIdempotent

Inspect

Export the current WorkPaper JSON document for persistence, review, or handoff to another agent. Does not write files by itself.

ParametersJSON Schema

Name	Required	Description	Default
`includeConfig`	No	Include workbook configuration metadata in the exported JSON. Defaults to true.

Output Schema

ParametersJSON Schema

Name	Required	Description
`document`	Yes	Persisted WorkPaper JSON document.
`sourcePath`	No
`serializedBytes`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already define readOnlyHint=true and no destructiveness. Description adds that export is in JSON format and does not write files, complementing annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that front-load purpose and key behavior. No wasted words.

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?

Given the output schema exists, the description adequately explains the tool's purpose, behavior, and parameter. No missing context for a simple export operation.

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 covers the single parameter 'includeConfig' with description. No additional parameter details needed beyond schema.

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?

Description clearly states the verb 'export', the resource 'WorkPaper JSON document', and the purpose 'persistence, review, or handoff to another agent'. It distinguishes from sibling tools which focus on cell/sheet operations.

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?

Description mentions 'Does not write files by itself' and lists use cases (persistence, review, handoff), providing context. However, it does not explicitly compare to siblings or state when not to use.

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

get_cell_display_valueGet WorkPaper Cell Display ValueA

Read-onlyIdempotent

Inspect

Return the formatted display string for one cell. Use when an agent needs what a user would see, not the raw numeric value.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Single A1 cell address such as B3.
`sheetName`	Yes	Existing sheet name.

Output Schema

ParametersJSON Schema

Name	Required	Description
`address`	Yes
`displayValue`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds the behavior of returning formatted display string, which is useful but not extensive beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no redundant information. Every word earns its place.

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?

Tool is simple with 2 required parameters, output schema exists, and description covers the essential behavior. No missing context given the tool's scope.

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 coverage is 100% with descriptions for both sheetName and address. Description does not add additional parameter semantics beyond what schema provides, so baseline 3 is appropriate.

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?

Description clearly states 'Return the formatted display string for one cell' with specific verb and resource. Distinguishes from siblings by contrasting with 'raw numeric value', which differentiates it from read_cell.

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 says 'Use when an agent needs what a user would see, not the raw numeric value', providing clear context for usage. Does not list alternatives but implies the opposite case.

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

list_sheetsList WorkPaper SheetsA

Read-onlyIdempotent

Inspect

Discover sheet names and used dimensions before reading or editing a WorkPaper. Returns metadata only; use read_range or read_cell for values.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`sheets`	Yes
`writable`	Yes	Whether set_cell_contents persists edits back to the source JSON file.
`sourcePath`	No	Absolute JSON file path when the server was started with --workpaper.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds contextual behavior by stating 'Returns metadata only', which aligns with annotations. It provides additional value by explaining the tool's role in workflows, but does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with only two sentences. It front-loads the purpose immediately and ends with clear alternatives. Every sentence adds value without redundancy.

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?

Given no parameters, rich annotations, and an output schema, the description is largely complete. It effectively communicates the tool's role and when to use siblings. Could be slightly more explicit about 'used dimensions' meaning, but with output schema, it's sufficient.

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?

The tool has no parameters, and schema description coverage is 100%. With no parameters to describe, the description cannot add meaning beyond the schema. Baseline score of 3 is appropriate.

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?

The description clearly states the tool's purpose: 'Discover sheet names and used dimensions before reading or editing a WorkPaper.' It uses a specific verb ('Discover') and resource ('sheet names and used dimensions'), and distinguishes itself from sibling tools by explicitly directing users to use 'read_range or read_cell for values'.

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?

The description explicitly tells when to use this tool ('before reading or editing a WorkPaper') and what not to use it for ('use read_range or read_cell for values'). It names alternative sibling tools, providing clear guidance on tool selection.

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

read_cellRead WorkPaper CellA

Read-onlyIdempotent

Inspect

Read one cell with calculated value, display text, formula text, and serialized content. Use after set_cell_contents to verify readback.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Single A1 cell address such as B3.
`sheetName`	Yes	Existing sheet name.

Output Schema

ParametersJSON Schema

Name	Required	Description
`value`	Yes	Calculated cell value.
`address`	Yes	Canonical sheet-qualified A1 address.
`formula`	Yes	Formula text without losing the original calculated value context, or null for literal cells.
`serialized`	Yes	Raw serialized cell content; formulas are strings that start with =.
`displayValue`	Yes	Formatted value as a user would see it.

TDQS

A4/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds what fields are returned (calculated value, display text, etc.) but does not add behavioral traits beyond annotations. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. Front-loaded with purpose and usage guidance.

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?

With an output schema present, the description need not explain return values. It covers usage context and differentiates from siblings. Could mention that address must be a single cell, but that is in the schema.

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 coverage is 100% with clear parameter descriptions. The description does not add additional meaning beyond the schema. Baseline of 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?

The description explicitly states it reads a single cell and returns calculated value, display text, formula text, and serialized content. It distinguishes from siblings like `get_cell_display_value` (likely simpler) and `read_range` (reads range).

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?

The description recommends using this tool after `set_cell_contents` to verify readback, providing clear context. However, it does not mention when not to use it or suggest alternatives like `get_cell_display_value` for simpler needs.

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

read_rangeRead WorkPaper RangeA

Read-onlyIdempotent

Inspect

Read calculated values plus serialized formulas/inputs for an A1 range. Use for audit readback after edits; use read_cell for one address.

ParametersJSON Schema

Name	Required	Description	Default
`range`	Yes	A1 range such as Summary!A1:B5. If omitted from the range, pass sheetName separately.
`sheetName`	No	Default sheet name when range omits a sheet name, for example Summary.

Output Schema

ParametersJSON Schema

Name	Required	Description
`range`	Yes	Canonical A1 range including the sheet name.
`values`	Yes	Two-dimensional array of evaluated cell values.
`serialized`	Yes	Two-dimensional array of raw serialized cell contents, including formulas.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already provide readOnlyHint, destructiveHint, idempotentHint. Description adds that it returns both calculated values and serialized formulas/inputs, which is helpful beyond annotations, though some additional behavioral details (e.g., case sensitivity) are not mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste, front-loaded with key action and resource, then usage guidance.

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?

Given complexity (2 params, output schema exists), description covers purpose, usage, and behavioral context. Output schema eliminates need to describe return values.

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 baseline is 3. Description mentions 'A1 range such as Summary!A1:B5' and combining range with sheetName, but adds minimal new meaning beyond the schema.

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?

Description clearly states the tool reads calculated values plus serialized formulas/inputs for an A1 range, distinguishing it from sibling read_cell which is for one address.

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?

Explicitly states 'Use for audit readback after edits; use read_cell for one address', providing clear when-to-use and when-not-to-use guidance.

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

set_cell_contentsSet WorkPaper Cell ContentsA

DestructiveIdempotent

Inspect

Write raw content to one cell, recalculate dependents, atomically persist the WorkPaper JSON file, and return before/after/restored readback.

ParametersJSON Schema

Name	Required	Description
`value`	Yes	Raw cell content. Formula strings must start with =; plain strings are stored as literals.
`address`	Yes	Single A1 cell address such as B3. Ranges are not accepted.
`sheetName`	Yes	Existing sheet name, for example Inputs.

Output Schema

ParametersJSON Schema

Name	Required	Description
`after`	Yes
`before`	Yes
`checks`	Yes
`restored`	Yes
`editedCell`	Yes	Canonical sheet-qualified address that was edited.
`persistence`	Yes

TDQS

A4/5.0

Behavior4/5

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

Discloses behaviors beyond annotations: recalculation of dependents, atomic persistence, and return of before/after readback. Annotations already declare destructiveHint=true and idempotentHint=true, and description aligns without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence that efficiently conveys all key actions: write, recalculate, persist, return. Front-loaded with the main purpose. No extraneous words.

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?

Given the presence of annotations, output schema, and sibling tools, the description adequately covers tool behavior and side effects. Minor omission of error handling or permission requirements, but acceptable for a focused write tool.

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 has 100% description coverage for all three parameters. Description adds minimal extra meaning beyond 'Write raw content to one cell' and the note about formula strings, which is already in the schema. Baseline 3 is appropriate.

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?

Description starts with 'Write raw content to one cell,' which clearly states the verb and resource. It distinguishes from siblings like read_cell or read_range by specifying write, recalculate, persist, and return readback.

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

Usage Guidelines3/5

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

No explicit when-to-use or when-not-to-use guidance. Implies use for writing cell content, but lacks alternatives or prerequisites. Could benefit from mentioning when to use validate_formula or read_cell instead.

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

validate_formulaValidate WorkPaper FormulaA

Read-onlyIdempotent

Inspect

Validate formula syntax with the WorkPaper parser before writing it to a cell. This checks syntax only; use set_cell_contents plus readback to evaluate.

ParametersJSON Schema

Name	Required	Description	Default
`formula`	Yes	Formula string including the leading =, for example =SUM(Inputs!B2:B4).

Output Schema

ParametersJSON Schema

Name	Required	Description
`valid`	Yes
`formula`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds value by clarifying that validation is syntax-only and does not evaluate, which complements the annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no extraneous wording, front-loaded with purpose and key constraint. Every sentence serves a purpose.

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?

Given the simple parameter, strong annotations, and presence of an output schema, the description covers purpose, usage guidance, and behavioral notes completely, leaving no gaps for the agent.

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?

With 100% schema description coverage for the single parameter, the description does not add significant meaning beyond the schema's description of the formula string. The reference to 'WorkPaper parser' provides mild context but does not enhance semantics.

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?

Description clearly identifies the tool as validating formula syntax using the WorkPaper parser, and distinguishes it from writing or evaluating formulas by stating 'checks syntax only' and suggesting set_cell_contents plus readback for evaluation.

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?

The description explicitly advises using this tool before writing a formula to a cell, and contrasts it with set_cell_contents plus readback for evaluation, providing clear when-to-use and when-not-to-use guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

No tool schema history has been recorded yet.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation4/5

Tools are mostly distinct, but read_cell and read_range overlap somewhat; descriptions help differentiate them. get_cell_display_value and read_cell both retrieve cell content, albeit different aspects.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, making them predictable and easy to understand.

Tool Count5/5

7 tools is appropriate for a WorkPaper server, covering essential operations without being overwhelming or insufficient.

Completeness3/5

The tool set covers basic read/write and validation, but lacks batch operations (e.g., write range), sheet management (add/delete), or formatting, leaving notable gaps for complex workflows.

Maintenance

ActivityNo data

ResponsivenessResponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

FilloOAuth
io.github.jacobfunch
Fillo MCP server — provision, scaffold, publish, and query forms from your coding agent.
Developer Tools App Automation
1
Pdfrender A
dev.pdfrender
HTML-to-PDF MCP server — render pixel-faithful PDFs from HTML.
Workplace & Productivity
11
Crane LedgerOAuth
ai.craneledger
Headless API-first double-entry accounting & bookkeeping engine. 84 MCP tools over HTTP.
Finance ERP Systems
2
QuillCaddie MCPOAuth
com.quillcaddie.www
OAuth-protected, read-only-by-default MCP server for provenance-labeled QuillCaddie project memory.
Knowledge & Memory Project Management
2

Related MCP Servers

formulon-mcp
Workplace & Productivity File Systems
libraz
A
license
Not graded
quality
A
maintenance
MCP server for Excel-compatible formula evaluation and workbook operations, enabling agents to open, inspect, mutate, recalculate, and save .xlsx files in-memory over stdio.
Updated 15 days ago (2026-08-22 15:49 UTC)
83
Apache 2.0
animus-document-engine
Workplace & Productivity Developer Tools
launchapp-dev
F
license
A
quality
C
maintenance
MCP server for rendering, parsing, converting, and editing Office documents (Excel, PowerPoint, Word) from a structured JSON spec, using LibreOffice WASM for conversion and preview.
Updated 2 months ago (2026-07-16 21:54 UTC)
5
1
-
mcp-excel
File Systems Developer Tools
Corvalon
A
license
Not graded
quality
B
maintenance
Provides full read and write access to Excel workbooks (sheets, cell ranges, tables, formulas, formatting, and cross-workbook references) via MCP, running locally or as an HTTP/SSE service.
Updated 2 days ago (2026-09-03 23:17 UTC)
70
MIT
regulated-reporting-mcp
Finance Legal & Compliance
dbett4
A
license
B
quality
A
maintenance
MCP server for regulated financial reporting on Workiva, enabling agents to search, read, and write to Workiva workbooks with policy-gated mutations, readback verification, and immutable receipts. Supports both a compact 3-tool facade and a full 117-tool catalog, plus a credential-free mock mode.
Updated 22 days ago (2026-08-15 19:13 UTC)
100
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/proompteng/bilig'

If you have feedback or need assistance with the MCP directory API, please join our Discord server