Skip to main content
Glama
hermoso-ai

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Edit a Google Doc in place

update_doc
DestructiveIdempotent

Edit Google Docs safely: replace exact text, rewrite the whole body, or set dropdown chips, with match counts and confirmation for destructive changes.

Instructions

EDIT a Google Doc — the correction append_to_doc cannot make. Two shapes: replacements:[{find, replace}] rewrites specific text wherever it appears (call read_doc first and match the text EXACTLY; matchCase:false ignores case), or rewrite:"…" replaces the ENTIRE body (rewrite:"" empties it), or dropdowns:[{title, value}] sets a dropdown chip (e.g. Status -> Approved — read_doc lists every chip with its options; pass dropdownId when two share a title; an unknown title or option is refused with the real list and nothing changes); the same entry with options:[…] (the COMPLETE new list, 2–50) and/or newTitle changes the dropdown itself for every chip built from it, and an option you drop that a chip shows needs replace:{"Old":"New"}. Find/replace runs immediately and REPORTS how many occurrences changed — zero matches is reported as a FAILURE to match, never as a quiet success, because a text edit that silently does nothing is worse than one that visibly fails. A whole-body rewrite is destructive: call it without confirm first to get the character count, then confirm:true + confirmCells. Both are index-free by design — an agent cannot reliably compute Google’s character offsets, and a wrong offset deletes the wrong sentence.

Input Schema

NameRequiredDescriptionDefault
docUrlNoa Google Docs URL — the id is extracted from it
confirmNo
rewriteNoreplace the WHOLE body with this text ("" empties the doc)
dropdownsNodropdown chips to set, or dropdowns to change
documentIdNothe document id (from create_doc, or list_drive_files for one the user picked)
confirmCellsNoecho back the character count the unconfirmed call reported (rewrite only)
replacementsNofind/replace pairs, applied in order

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.398
    • changedInput schema / properties / dropdowns / description
      Previous value: -"dropdown chips to set"New value: +"dropdown chips to set, or dropdowns to change"
    • addedInput schema / properties / dropdowns / items / properties / newTitle
      Added value: +{
+  "description": "rename the dropdown",
+  "type": "string"
+}
    • addedInput schema / properties / dropdowns / items / properties / options
      Added value: +{
+  "description": "change the dropdown itself: the COMPLETE new option list (2–50) by display text; existing options keep their colour; shared by every chip built from it",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / dropdowns / items / properties / replace
      Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "description": "for an option you remove that a chip shows: {\"Old\": \"New\"}",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}
    • removedInput schema / properties / dropdowns / items / required
      Removed value: -[
-  "value"
-]
  2. Changed1 schema field changedv0.1.372
    • addedInput schema / properties / dropdowns
      Added value: +{
+  "description": "dropdown chips to set",
+  "items": {
+    "properties": {
+      "dropdownId": {
+        "description": "when two dropdowns share a title",
+        "type": "string"
+      },
+      "tabId": {
+        "type": "string"
+      },
+      "title": {
+        "description": "the dropdown title (from read_doc)",
+        "type": "string"
+      },
+      "value": {
+        "description": "the option to select, by its display text",
+        "type": "string"
+      }
+    },
+    "required": [
+      "value"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
  3. Addedv0.1.161

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the supplied annotations, the description discloses critical behavior: find/replace reports occurrences changed and treats zero matches as a failure, whole-body rewrite is destructive and requires an unconfirmed probe followed by confirm:true plus confirmCells, and unknown dropdown titles or options are refused without changes. It also explains that the design is index-free because agents cannot reliably compute Google offsets.

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?

The description is front-loaded with the core purpose and supported shapes, and every clause adds operational value. However, it is a dense run-on paragraph with heavy punctuation, which makes it harder to scan than a more structured presentation would be.

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?

For a complex 7-parameter edit tool with no output schema, the description covers purpose, prerequisites, destructive confirmation, failure semantics, dropdown edge cases, and sibling differentiation. An agent has enough information to invoke the tool correctly and interpret the main outcomes.

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

Parameters5/5

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

With schema coverage already at 86%, the description adds substantial meaning beyond the schema: replacement matching behavior, matchCase:false semantics, rewrite:'' emptying the document, dropdown option lists being complete and limited to 2–50, dropdownId for duplicate titles, and the confirm/confirmCells confirmation flow.

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 states a specific verb and resource — editing a Google Doc in place — and explicitly differentiates from the sibling append_to_doc by framing this as 'the correction append_to_doc cannot make.' It also enumerates the supported edit shapes, so an agent can identify the tool without opening 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 Guidelines5/5

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

The description names the sibling alternative (append_to_doc) and explains when this tool is needed: for corrections that append cannot make. It also gives concrete prerequisites and alternatives within the workflow, such as calling read_doc first and matching text exactly.

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

Deploy Server

Other Tools