Skip to main content
Glama
hermoso-ai

Hermoso

Official

Edit a Google Doc in place

update_doc
DestructiveIdempotent

Edit a Google Doc: find and replace exact text, rewrite or empty the whole body, or set dropdown chips. Reports match counts and requires confirmation before destructive rewrites.

Instructions

EDIT a Google Doc — the correction append_to_doc cannot make, which until now meant a doc could only ever grow and a wrong line stayed in it forever. 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). 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

TableJSON 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
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. 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"
      +}
  2. Addedv0.1.161

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds what the annotations cannot: zero matches is surfaced as a failure rather than silent success, an unknown dropdown title/option is refused with the real option list and nothing changes, and whole-body rewrite requires confirm + confirmCells echoing the reported character count. The index-free design rationale explains why offsets are not accepted.

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 the verb and the three shapes before any detail, and most sentences carry operational content. It is long and includes some editorializing ('a text edit that silently does nothing is worse than one that visibly fails'), which costs a point but does not obscure the actionable parts.

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 destructive, multi-mode mutation tool with no output schema, the description covers mode selection, the confirmation protocol, error semantics on failed matches, and what gets reported back. Nothing an agent needs to call it safely is missing.

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 86%, so the schema carries most parameter documentation (docUrl, documentId, dropdownId, confirmCells). The description still adds real meaning beyond it: matchCase:false ignores case, rewrite:"" empties the doc, dropdownId is only needed when two chips share a title, and replacements run in order.

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?

Opens with a specific verb+resource ('EDIT a Google Doc') and immediately distinguishes itself from the sibling append_to_doc by naming the capability append cannot provide (correcting existing text). An agent can pick this over append_to_doc or read_doc without opening any 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?

Explicit routing: use replacements for targeted fixes, rewrite for the whole body, dropdowns for chips; it tells the agent to call read_doc first and match text EXACTLY, and it prescribes the two-step confirm flow for destructive rewrites. Alternatives and their selection conditions are stated, not implied.

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