Skip to main content
Glama

update_doc_section

Replace a single section of a workspace's doc body, identified by its heading text. The targeted edit complement to update_doc (full replacement) and append_doc_section (append-only at the end). Use this when the agent maintains a recurring section (e.g., a 'Status' block in a launch-prep doc, an 'Outcomes' block in a meeting note) and only needs to refresh that one piece. Without it, agents are forced into 'GET → splice → PUT' which costs tokens, costs latency, and races against any concurrent human edit elsewhere in the doc (last-write-wins clobbers). Section semantics: the FIRST heading whose plain text matches heading exactly (case-sensitive on trimmed text) is found, and everything from that heading up to the next heading at the same OR shallower level is replaced. So a ## Outcomes section ends at the next ## … or # …; nested ### … subsections stay part of the replaced range. Returns 404 when no matching heading exists; strict by design so a misremembered heading fails loudly. markdown is the FULL replacement, INCLUDING the heading line: pass it back as-is to keep the heading, change it to rename or rewrite the heading, change the heading level, or omit the heading entirely (collapses the section into the prior one). Empty markdown deletes the section. Same markdown surface as update_doc / append_doc_section (CommonMark + GFM + ![alt](url) images + lone-URL videos (mp4/webm/mov/mkv/m4v) + Mermaid + KaTeX + callouts + SVG + details + cross-refs + @-mentions + URL embeds). Identity / attribution / events / doc-guard all flow through the same writeDocBody path as the other doc endpoints, so @-mentions in the new section fire doc.mention_added for newly-added mentions just like update_doc does. Requires editor role. Multi-surface workspaces optionally accept surface_slug to target a specific doc tab. WARNING — a section runs to the next heading of the SAME OR SHALLOWER level, so targeting the LAST heading (or a lone H1) means its section extends to the END OF THE DOCUMENT and this call replaces everything below it. That has silently destroyed a doc twice (#8196), both times returning success. Call get_doc first and check which headings follow the one you are targeting. Agent writes that would drop most of the doc's blocks are now REFUSED with both block counts; pass allowBlockLoss: true to confirm an intended large deletion.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYesThe workspace slug. Accepts either the bare slug ('my-workspace') or the org-prefixed form ('my-org/my-workspace').
headingYesPlain text of the heading to find (case-sensitive, trimmed). For `## Outcomes`, pass `Outcomes`. Hash marks and surrounding whitespace are stripped from the comparison automatically by the markdown converter. Use `get_doc` first if you need to enumerate the headings actually present.
markdownYesFULL replacement markdown for the section, including the heading line if you want to keep / rename / restructure it. Empty string deletes the section.
surface_slugNoOptional doc surface slug for multi-doc workspaces. Omit to target the primary doc surface.
allowBlockLossNoConfirm a replacement that removes most of the document. Omit it normally: the call is refused (with the previous and new block counts) when it would destroy the bulk of the doc, which is what a trailing-heading target does. Set true only when the deletion is what you intend.

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries full behavioral burden and delivers thoroughly: section-boundary semantics, strict 404 on missing heading, empty-markdown deletion, refusal with block counts unless `allowBlockLoss: true`, @-mention event behavior, and a prominent warning about trailing headings that 'has silently destroyed a doc twice (#8196)'. This is exceptional transparency.

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 long but front-loaded and densely informative. Every paragraph earns its place: purpose first, then semantics, then a critical safety warning. The length is justified by the tool's hazards and by the absence of annotations and output schema.

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?

Despite having no output schema, the description covers return/error behavior (404, successful deletion confirmations, refusal with block counts), prerequisites (editor role), optional `surface_slug` handling, supported markdown surface, and dangerous edge cases. The only minor gap is the exact success shape, but 'returning success' is mentioned, and all critical operational context is present.

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 100%, but the description adds meaning beyond it: it clarifies that `markdown` includes the heading line and how omitting or changing it affects structure, explains the exact heading-matching rule (FIRST, case-sensitive, trimmed) and section extent, and elaborates the `allowBlockLoss` refusal trigger. These additions materially improve correct invocation.

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 precise verb and resource: 'Replace a single section of a workspace's doc body, identified by its heading text.' It immediately distinguishes itself from siblings by naming `update_doc` (full replacement) and `append_doc_section` (append-only), making selection unambiguous.

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 when-to-use guidance is given: recurring sections like a 'Status' block or 'Outcomes' block that need one-piece refresh. It contrasts with the costly 'GET → splice → PUT' alternative, names the two sibling alternatives, advises calling `get_doc` first, and states the editor role requirement.

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.

TDQS

A3.8/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, with detailed descriptions that prevent confusion. The main ambiguity arises from send_message vs. the referenced but missing message_teammate tool, and add_column vs. update_surface for schema changes, but these are mostly clarified by the descriptions.

Naming Consistency4/5

The naming convention is predominantly verb_noun with underscores (e.g., create_workspace, list_rows, update_doc). Exceptions like 'search' and 'address_book' (no noun) and the two-word 'react_to_comment' are minor deviations in an otherwise consistent pattern.

Tool Count1/5

With 68 tools, the surface is far too large for an MCP server, exceeding the 50+ threshold for extreme mismatch. This volume creates excessive selection overhead for agents and suggests the tool set could be consolidated or split into focused servers.

Completeness3/5

The server covers broad functionality across workspaces, docs, tables, HTML, comments, files, webhooks, and billing. However, notable gaps exist: the explicitly referenced message_teammate tool is missing (preventing agent-to-agent waking), and there is no create/upload file tool or create API key tool, which creates dead ends in workflows.