Skip to main content
Glama

hedwigai

Ask a workbook to change

update_workbook

Starts a run on the workbook, described in one sentence the way a person would say it — 'add a section on Q3 headcount', 'refresh the cash figures from the latest filing'. The run is billed to this account and takes minutes; this returns its run id immediately and does not wait. The workbook shows what changed once the run finishes. An instruction that is a question about the workbook — 'which rows have no source?' — is answered instead, in seconds, from the workbook's own text: no version is written, and read_workbook's messages holds the answer under this run's id. On a flashroom workbook the run takes seconds, and the answer is a plan: each cell's before and after, and any folders and files. A plan changes nothing; the instruction yes in a later call makes it, as a new version.

Input Schema

NameRequiredDescriptionDefault
modeNoWhat this workbook's runs are, from now on. `harnessroom` (a new workbook's default): the instruction is a request, and a harness researches and writes the document. `latticeroom`: the instruction is a draft someone already wrote, whole — markdown, its links kept — which comes back exactly as written, with the run's inference beside it (read_workbook's `inference`: each claim cited, self-reported, secondary only, contradicted or with no source, and its sources); each entry under its References or Bibliography heading is looked up in Crossref and on the web and marked found, found with other authors or year, or not found, and a sentence citing it — [3], (Smith et al., 2020) — is read against the work found; attach data files (.json, .csv, .tsv) to settle the draft's own figures. `graphroom`: runs perform the procedure drawn for the workbook in the app, and refuse until one is drawn. `flashroom`, for a workbook made from a spreadsheet or a Word document: the instruction is an edit to its sheet, or to the document's table it is about, planned in seconds and kept in `messages` — each cell's before and after, the rows added and removed — and nothing is written until the next instruction is `yes`, which makes it as a new version. Omit to keep the workbook's current mode.
workNotrue when the instruction is work to do and never a question — your own router already said so. The run starts without first being asked whether it is a question.
contextNoExplain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
workbookYesThe workbook id.
llm_modelNoThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
attachmentsNoFiles to attach to the workbook BEFORE the run starts, so it reads and cites them — each {name, content_base64, content_type?}, 32 MB at most. They stay attached for every later run; list_attachments shows them.
instructionYesWhat should change, in one sentence — or, for a latticeroom, the whole draft to ground.
sources_folderNoThe drive folder you keep this workbook's subject in — `/dropbox/Trevi Therapeutics`. What the run cites is filed there once it delivers, instead of a folder named after the document's title.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / mode / description
      Previous value: -"What this workbook's runs are, from now on. `harnessroom` (a new workbook's default): the instruction is a request, and a harness researches and writes the document. `latticeroom`: the instruction is a draft someone already wrote, whole — markdown, its links kept — which comes back exactly as written, with the run's inference beside it (read_workbook's `inference`: each claim cited, self-reported, secondary only, contradicted or with no source, and its sources); each entry under its References or Bibliography heading is looked up in Crossref and on the web and marked found, found with other authors or year, or not found, and a sentence citing it — [3], (Smith et al., 2020) — is read against the work found; attach data files (.json, .csv, .tsv) to settle the draft's own figures. `graphroom`: runs perform the procedure drawn for the workbook in the app, and refuse until one is drawn. Omit to keep the workbook's current mode."New value: +"What this workbook's runs are, from now on. `harnessroom` (a new workbook's default): the instruction is a request, and a harness researches and writes the document. `latticeroom`: the instruction is a draft someone already wrote, whole — markdown, its links kept — which comes back exactly as written, with the run's inference beside it (read_workbook's `inference`: each claim cited, self-reported, secondary only, contradicted or with no source, and its sources); each entry under its References or Bibliography heading is looked up in Crossref and on the web and marked found, found with other authors or year, or not found, and a sentence citing it — [3], (Smith et al., 2020) — is read against the work found; attach data files (.json, .csv, .tsv) to settle the draft's own figures. `graphroom`: runs perform the procedure drawn for the workbook in the app, and refuse until one is drawn. `flashroom`, for a workbook made from a spreadsheet or a Word document: the instruction is an edit to its sheet, or to the document's table it is about, planned in seconds and kept in `messages` — each cell's before and after, the rows added and removed — and nothing is written until the next instruction is `yes`, which makes it as a new version. Omit to keep the workbook's current mode."
    • changedInput schema / properties / mode / enum
      Previous value: -[
      -  "harnessroom",
      -  "latticeroom",
      -  "graphroom"
      -]New value: +[
      +  "harnessroom",
      +  "latticeroom",
      +  "graphroom",
      +  "flashroom"
      +]
  2. Changed2 schema fields changed
    • addedInput schema / properties / sources_folder
      Added value: +{
      +  "description": "The drive folder you keep this workbook's subject in — `/dropbox/Trevi Therapeutics`. What the run cites is filed there once it delivers, instead of a folder named after the document's title.",
      +  "type": "string"
      +}
    • addedInput schema / properties / work
      Added value: +{
      +  "description": "true when the instruction is work to do and never a question — your own router already said so. The run starts without first being asked whether it is a question.",
      +  "type": "boolean"
      +}
  3. Changed1 schema field changed
    • changedInput schema / properties / mode / description
      Previous value: -"What this workbook's runs are, from now on. `harnessroom` (a new workbook's default): the instruction is a request, and a harness researches and writes the document. `latticeroom`: the instruction is a draft someone already wrote, whole — markdown, its links kept — which comes back exactly as written, with the run's inference beside it (read_workbook's `inference`: each claim cited, self-reported, secondary only, contradicted or with no source, and its sources); attach data files (.json, .csv, .tsv) to settle the draft's own figures. `graphroom`: runs perform the procedure drawn for the workbook in the app, and refuse until one is drawn. Omit to keep the workbook's current mode."New value: +"What this workbook's runs are, from now on. `harnessroom` (a new workbook's default): the instruction is a request, and a harness researches and writes the document. `latticeroom`: the instruction is a draft someone already wrote, whole — markdown, its links kept — which comes back exactly as written, with the run's inference beside it (read_workbook's `inference`: each claim cited, self-reported, secondary only, contradicted or with no source, and its sources); each entry under its References or Bibliography heading is looked up in Crossref and on the web and marked found, found with other authors or year, or not found, and a sentence citing it — [3], (Smith et al., 2020) — is read against the work found; attach data files (.json, .csv, .tsv) to settle the draft's own figures. `graphroom`: runs perform the procedure drawn for the workbook in the app, and refuse until one is drawn. Omit to keep the workbook's current mode."
  4. Changed3 schema fields changed
    • changedInput schema / properties / instruction / description
      Previous value: -"What should change, in one sentence — or, in `ground` mode, the whole draft to ground."New value: +"What should change, in one sentence — or, for a latticeroom, the whole draft to ground."
    • changedInput schema / properties / mode / description
      Previous value: -"What this workbook's runs do, from now on. `research` (a new workbook's default): the instruction is a request, and the run finds sources and writes the document. `ground`: the instruction is a draft someone already wrote, whole — markdown, its links kept — and the run leaves every word as written and marks each claim cited (with the passage quoted), self-reported, secondary only, contradicted or with no source. Link data files on the account's drive (/dropbox/...json, .csv) in the draft to settle its own figures. Omit to keep the workbook's current mode."New value: +"What this workbook's runs are, from now on. `harnessroom` (a new workbook's default): the instruction is a request, and a harness researches and writes the document. `latticeroom`: the instruction is a draft someone already wrote, whole — markdown, its links kept — which comes back exactly as written, with the run's inference beside it (read_workbook's `inference`: each claim cited, self-reported, secondary only, contradicted or with no source, and its sources); attach data files (.json, .csv, .tsv) to settle the draft's own figures. `graphroom`: runs perform the procedure drawn for the workbook in the app, and refuse until one is drawn. Omit to keep the workbook's current mode."
    • changedInput schema / properties / mode / enum
      Previous value: -[
      -  "research",
      -  "ground"
      -]New value: +[
      +  "harnessroom",
      +  "latticeroom",
      +  "graphroom"
      +]
  5. Changed2 schema fields changed
    • changedInput schema / properties / instruction / description
      Previous value: -"What should change, in one sentence."New value: +"What should change, in one sentence — or, in `ground` mode, the whole draft to ground."
    • addedInput schema / properties / mode
      Added value: +{
      +  "description": "What this workbook's runs do, from now on. `research` (a new workbook's default): the instruction is a request, and the run finds sources and writes the document. `ground`: the instruction is a draft someone already wrote, whole — markdown, its links kept — and the run leaves every word as written and marks each claim cited (with the passage quoted), self-reported, secondary only, contradicted or with no source. Link data files on the account's drive (/dropbox/...json, .csv) in the draft to settle its own figures. Omit to keep the workbook's current mode.",
      +  "enum": [
      +    "research",
      +    "ground"
      +  ],
      +  "type": "string"
      +}
  6. Changed2 schema fields changed
    • addedInput schema / properties / context
      Added value: +{
      +  "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\"",
      +  "type": "string"
      +}
    • addedInput schema / properties / llm_model
      Added value: +{
      +  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
      +  "type": "string"
      +}
  7. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations, the description discloses billing ('billed to this account'), latency ('takes minutes', 'seconds' on flashroom), async semantics ('returns its run id immediately and does not wait'), and the side-effect boundary ('no version is written' for questions, 'A plan changes nothing'). That is exactly the behavioral context the annotations alone cannot convey.

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?

Core action and async/billing facts are front-loaded, and every sentence carries substantive information about modes, questions, or plans. It is dense and long for a tool description, with mode-specific detail that could be tighter, but there is little true 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?

For a complex 8-parameter, multi-mode mutation with no output schema, the description covers return value (run id), result delivery (workbook shows changes; read_workbook's messages holds answers), and per-mode semantics. Minor gaps remain around failure/refusal conditions outside graphroom and quota limits on the run, but the essentials an agent needs to invoke correctly are present.

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 coverage is 100%, so baseline is 3. The description adds real semantic guidance on `instruction` phrasing ('the way a person would say it' with examples), on `mode` behavior (graphroom refusal, flashroom planning, omitting to keep current), and on attachments persisting across runs — more than the schema alone provides.

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 opens with a concrete verb and resource — 'Starts a run on the workbook' — and immediately characterizes the instruction as a one-sentence request with examples. It also delineates the alternate behavior (questions answered inline) which distinguishes the call from siblings like answer_question and read_workbook without needing 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 Guidelines4/5

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

It provides clear when-to-use context: an instruction that is a request starts a run; a question is answered in seconds from the workbook's own text; a `yes` instruction in a later call commits a flashroom plan. It does not explicitly name answer_question or commit_workbook as alternatives, leaving the agent to infer routing from behavior rather than sibling names.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.