Skip to main content
Glama

Write a doc or a tab

write_doc

Writes markdown content to a Google Doc path, creating new documents or replacing existing ones after confirming any potential data loss.

Instructions

Write markdown-rendered content to a path, like the local Write tool. A path that names nothing is CREATED and never asks, but only an absolute path (or a Drive id or URL start) creates: a bare name like Contract is refused with the full path to call. When the project has a default folder for new docs, a new doc at the top of My Drive (/Contract) is refused once too, with the default folder’s full path to call, so the user is told where it goes first; the same call repeated goes through: /Work/Contract creates a doc in the folder /Work, /Work/Contract/Notes a tab in that doc, /Work/Contract/Part 2/Ch.4 a child tab under Part 2 (only the last step may be new; make the folder with drive mkdir first). A path that names something is REPLACED, and the first call is refused with a loss summary — the paragraphs of text and everything a read cannot carry that the replace would take with it: comments, suggestions, tab stops, links to bookmarks, section breaks, a table of contents, column breaks, equations, page-number fields, a date in a format the API can only read, and a link chip to anything but a Drive file — plus a confirmLoss string. Ask the user before anything else — show them what would be lost and wait for a yes; never pass confirmLoss on your own. Only after their yes, call again with the same content and confirmLoss set to that string exactly. If the doc changed in between, the string no longer matches and the call is refused again with a fresh summary. A doc with several tabs needs a tab step (the refusal lists them); a doc with one tab means that tab. Nothing to lose, nothing to ask: an empty doc, tab, header or footer is written without the refusal. segment: "header" or "footer" writes the page header or footer of an existing doc instead of its body: a missing default one is created and written, an existing one with content is replaced after the same confirmLoss round-trip, and a missing first-page or even-page one (page: "first" / "even") is refused with the instruction to turn on Different first page in Docs. Replacing keeps the doc’s title, sharing and other tabs but the new paragraphs start unstyled, so anything not in the markdown (including indents) is gone; prefer edit_doc to change a document, which keeps everything its anchor does not cover. Style is CSS, in the spelling read_doc emits: a leading block sets the named styles (p, h1–h6, .title, .subtitle), / / style a paragraph, a run. Supported: text-align, line-height, margin-top/bottom/left/right, text-indent (pt; text-indent is relative to margin-left), and on spans/rules font-family, font-size, font-weight, font-style, text-decoration, color. Any other property fails the whole write before anything is sent, listing every offending line. Footnotes, dates, person chips, Drive link chips and dropdowns are written back as read_doc spells them ([^1] and a [^1]: note line; ; ; with its line); --- is written as an empty paragraph with a thin grey bottom border. A new column break, equation, page-number field, or link chip to anything but a Drive file (YouTube, Calendar, Maps, a web page) is refused before anything is sent: the API cannot make it, so write text for a link, or ask the user to insert the rest in Google Docs. A chip’s text is Google’s, so a chip given other words is refused. A page break is on a line of its own (also accepted: , break-before: page, break-after: page); any other or is refused. For long documents, pass contentFile instead of content so the server reads the body directly (retyping a long doc inline can silently drop text). Returns images ({src, objectId}) for pushed images. suggest: true sends the replace as suggestions for a person to accept or reject in Docs, and never asks for confirmLoss: nothing is lost until a person accepts, and rejecting brings back the text, images, tables and comments as they were. It needs a path that already names something (a new doc or tab cannot be a suggestion), refuses a table column width (Docs cannot suggest one) before anything is sent, and lists the suggestion ids in suggestions; use it when the user wants to review the rewrite or the doc is not theirs. It defaults to false: the replace is applied as live text.

Input Schema

NameRequiredDescriptionDefault
pageNowhich header/footer, when a doc defines more than one (default-page, first-page, even-page). Omit to use whichever exists.
pathYesThe doc or tab to write: /folder/doc, /folder/doc/tab, /folder/doc/tab/child, or a doc id or URL followed by tab steps. A path that does not exist yet is created (only its last step may be new).
accountNoGoogle account email to use. Defaults to GDOCS_DEFAULT_ACCOUNT, or the sole account.
baseDirNoabsolute dir to resolve relative local image paths against (e.g. the markdown file’s folder)
contentNomarkdown content (or use contentFile)
segmentNowhich content tree to target: body (default), or the page header/footer. Header/footer content is invisible to a body read — a letterhead logo lives there.
suggestNosend the replace as suggestions for a person to accept or reject, instead of applying it (default false)
confirmLossNothe confirmLoss string from the refusal, passed back exactly, after the user has agreed to what it lists. Never needed when creating, or with suggest.
contentFileNopath to a local markdown/text file to use as the body, read directly by the server — preferred for long documents so the body is passed through mechanically rather than retyped inline (which can silently drop text). Absolute, or relative to baseDir. Mutually exclusive with content.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the two-step refusal/confirmLoss loss-summary protocol, what exactly would be destroyed (comments, suggestions, tab stops, TOC, equations, chips), that replacement resets paragraph styling, that unsupported CSS fails the whole write before anything is sent, and that suggest mode is reversible. This is a genuinely rare level of mutation-risk disclosure.

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

Conciseness3/5

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

Almost every clause earns its place, but the body is a single very long paragraph mixing path semantics, styling rules, chip encoding, refusal behavior, and suggest mode, which makes it hard to scan under context pressure. It is front-loaded correctly (create/replace first), but structure could be improved with grouping.

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 9-parameter mutation tool with no annotations and no output schema, coverage is strong: creation, replacement, headers/footers, styling, special elements, long-content handling, and suggestion mode are all covered. The only modest gap is that the return value is described in a single clause ('Returns images') without indicating what a successful write otherwise returns.

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?

Schema coverage is already 100%, but the description adds real semantics on top: path creation rules (absolute/id/URL only, bare names refused with the full path to call), the default-folder second refusal, tab-step nesting rules, segment header/footer behavior including the first/even refusal, page-type behavior, and page-break encodings. Nothing critical is left to schema inference alone.

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: 'Write markdown-rendered content to a path', and immediately establishes the create-vs-replace dichotomy that defines the tool. It also explicitly routes away from the closest sibling ('prefer edit_doc to change a document'), so an agent can distinguish it from edit_doc/read_doc without opening schemas.

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?

Gives concrete when-to-use rules: use contentFile for long documents, use suggest when the user wants to review or the doc isn't theirs, use edit_doc for in-place changes, and use drive mkdir before creating nested folders. It also states when NOT to act (never pass confirmLoss on your own; ask the user first) and enumerates what gets refused.

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