Bilig WorkPaper

Set WorkPaper Cell Contents And Read Back

set_cell_contents_and_readback

Idempotent

Write raw content to one cell, recalculate dependents, read a dependent range in the same tool call, and return persistence proof. Use this for stateless MCP clients such as hosted Open WebUI integrations.

Input Schema

TableJSON Schema

Name	Required	Description
`value`	Yes	Raw cell content. Formula strings must start with =; plain strings are stored as literals. Strict MCP hosts require a single parameter type, so pass evaluated numbers/booleans as formulas such as =0.4 or =TRUE(). The server still accepts JSON number, boolean, or null arguments from clients that support them.
`address`	Yes	Single A1 cell address to edit, such as B3. Ranges are not accepted.
`sheetName`	Yes	Existing sheet name for the cell to edit, for example Inputs.
`readbackRange`	Yes	Dependent A1 range to read before and after the edit, for example Summary!A1:B5.
`readbackSheetName`	No	Default sheet name when readbackRange omits a sheet name.

Output Schema

TableJSON Schema

Name	Required	Description
`after`	Yes
`before`	Yes
`checks`	Yes
`editedCell`	Yes	Canonical sheet-qualified address that was edited.
`persistence`	Yes
`afterReadback`	Yes
`readbackRange`	Yes	Canonical sheet-qualified range read before and after the edit.
`beforeReadback`	Yes
`restoredReadback`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed4 schema fields changedJun 2, 2026

addedOutput schema / properties / after / properties / formulaDiagnostics

Added value: +{
+  "description": "Structured formula diagnostics. Empty when the cell has no formula error.",
+  "type": "array"
+}

changedOutput schema / properties / after / required

Previous value: -[
-  "address",
-  "value",
-  "serialized",
-  "formula",
-  "displayValue"
-]New value: +[
+  "address",
+  "value",
+  "serialized",
+  "formula",
+  "displayValue",
+  "formulaDiagnostics"
+]

addedOutput schema / properties / before / properties / formulaDiagnostics

Added value: +{
+  "description": "Structured formula diagnostics. Empty when the cell has no formula error.",
+  "type": "array"
+}

changedOutput schema / properties / before / required

Previous value: -[
-  "address",
-  "value",
-  "serialized",
-  "formula",
-  "displayValue"
-]New value: +[
+  "address",
+  "value",
+  "serialized",
+  "formula",
+  "displayValue",
+  "formulaDiagnostics"
+]

AddedMay 27, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral context beyond this: it discloses that the tool recalculates dependents, performs a readback before and after the edit, and returns persistence proof—none of which are captured by the annotations and all of which are useful for an agent to anticipate the tool's effects.

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 two sentences, front-loaded with the core purpose, and contains no filler. Every clause adds information: the action, the recalculation step, the readback, the persistence proof, and the intended use case. Highly efficient.

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 tool's moderate complexity, the presence of an output schema (so return values are specified}, and full schema coverage for parameters, the description is complete. It covers what the tool does, why to use it, and important behavioral side effects (recalculation, persistence proof), leaving no critical gaps.

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 thoroughly documents all 5 parameters. The description itself does not add additional parameter-level detail; however, the schema's own descriptions are comprehensive, so the 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 function with a specific verb ('write'), resource ('cell'), and unique capability ('recalculate dependents', 'read a dependent range', 'return persistence proof'). It distinguishes itself from the sibling 'set_cell_contents' by explicitly combining write with readback in the same call.

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 gives explicit usage context: 'Use this for stateless MCP clients such as hosted Open WebUI integrations.' It implies the alternative (set_cell_contents) is for stateful clients, though it does not name alternatives explicitly or state when not to use it.

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

All Bilig WorkPaper tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation4/5

Tools are mostly distinct with clear purposes for reading, writing, exporting, and validating. Slight overlap exists between get_cell_display_value and read_cell, and between the two set_cell variants, but descriptions clarify the intended use.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., list_sheets, read_cell, validate_formula). This predictable naming makes the set easy to navigate.

Tool Count5/5

With 8 tools, the set is well-scoped for interacting with a WorkPaper document. Each tool serves a clear purpose without unnecessary bloat.

Completeness3/5

Core operations for reading, writing, validating, and exporting are covered, but the surface lacks batch cell writes, cell clearing, and sheet management. These notable gaps may hinder complex editing workflows.

Set WorkPaper Cell Contents And Read Back

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources