Skip to main content
Glama
ammarqaisar11a55

Google Docs MCP

by ammarqaisar11a55
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Local

Delete text from Google Doc

delete_text
Destructive

Delete a range of content from a Google Doc by index, with optional expectedText verification to guard against stale indexes.

Instructions

DESTRUCTIVE: delete the content in the index range [startIndex, endIndex) of a Google Doc (endIndex is exclusive). Get the indexes from get_document or find_text immediately before calling. Strongly recommended: pass expectedText with the exact text currently in that range (including any "\n" paragraph breaks); if it does not match, nothing is deleted and the current text is returned, which protects against stale indexes. The document’s final newline cannot be deleted (the maximum endIndex is bodyEndIndex-1). Deleting a paragraph break merges the two paragraphs; tables can only be deleted as a whole, although the text inside a cell can be deleted. Every later index shifts back by deletedLength. Deleted content can only be recovered from the Google Docs version history. To delete every occurrence of a phrase use replace_text with an empty replacementText.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endIndexYesEnd of the range (exclusive); must be greater than startIndex.
documentIdYesThe Google Docs document ID (the part between /d/ and /edit in the document URL). A full Google Docs URL is also accepted.
startIndexYesStart of the range (inclusive). Get exact indexes from get_document or find_text.
expectedTextNoThe exact text currently in [startIndex, endIndex). If given, the deletion is refused when the document text differs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

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, but the description adds substantial context beyond them: the expectedText mismatch guard (nothing deleted, current text returned), the un-deletable final newline, paragraph-merge on break deletion, whole-table-only deletion, index shifting, and version-history-only recovery.

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?

Long but front-loaded with the DESTRUCTIVE warning and endIndex exclusivity first. Every sentence carries operational information, though a few clauses could be tightened without losing meaning.

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?

Complete for a destructive mutation tool with no output schema: it discloses the guard's return behavior on mismatch, the index bounds invariant, and recovery limitations. 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 100%, so the schema already documents all four parameters and their semantics. The description still adds value by explaining the guard behavior of expectedText (including the "\n" paragraph-break requirement) and echoing the inclusive/exclusive index semantics.

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?

States a specific verb (delete), a precise resource (content in [startIndex, endIndex) of a Google Doc), and clarifies scope (endIndex exclusive). Clear differentiation from siblings like delete_document and replace_text.

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?

Explicitly says to obtain indexes from get_document or find_text immediately before calling, and routes the 'delete every occurrence' case to replace_text with an empty replacementText. Covers both when-to-use and the alternative.

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

Install Server

Other Tools