Skip to main content
Glama

gws-mcp__docs_get

Read-only

Get the content of a Google Doc. Three modes: "text" (default) returns plain text — use for reading/summarizing. "index" returns text with startIndex/endIndex — use before positional edits (insertText at index, deleteContentRange). "full" returns the raw API response — use only for debugging or style operations. To read part of a long document, pass start_index/end_index — the SAME character indices that mode "index" reports and docs_batch_update consumes. A ranged response also reports totalEndIndex, clipped, and nextStartIndex (when more content follows), so a caller can page instead of guessing whether it saw everything. Without a range, behaviour is unchanged and the whole document is returned.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "document_id": "<document_id>"
    },
    "name": "gws-mcp__docs_get"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNo"text" (default): plain text. "index": text with character positions for edits. "full": raw API response.
accountNoOptional email address of the connected account to use (e.g. 'user@gmail.com'). If omitted, the default account is used.
end_indexNoReturn content up to this character index (exclusive), same index space as start_index. Omit to read to the end.
document_idYesThe Google Docs document ID (from the URL)
start_indexNoReturn content from this character index (inclusive), in the same index space mode "index" reports and docs_batch_update consumes — a document body starts at index 1. Omit to read from the start. Not valid with mode "full".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses return-shape behavior for ranged reads (totalEndIndex, clipped, nextStartIndex for paging), the unchanged full-document behavior when no range is given, and the constraint that start_index is invalid with mode "full". These are non-obvious traits an agent cannot get from the annotations.

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 purpose then modes then paging, and nearly every clause carries distinct information. It is dense but slightly long, with the paging explanation and the "behaviour is unchanged" sentence partially overlapping in what they convey.

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 read-only getter with five fully documented parameters and no output schema, the description covers mode selection, index semantics, range paging, and the one invalid combination. An agent has everything needed to call it correctly without guessing.

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 baseline is 3, but the description adds genuine meaning: the index space is the same one mode "index" reports and docs_batch_update consumes, and a document body starts at index 1. That cross-tool index contract is not spelled out in the schema for start_index/end_index.

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 specific verb and resource ("Get the content of a Google Doc") and immediately enumerates the three modes with what each returns, which separates it from docs_batch_update, docs_write, and drive_read_file in the sibling list.

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?

Each mode carries an explicit use case: "text" for reading/summarizing, "index" before positional edits such as insertText/deleteContentRange, "full" only for debugging or style operations. It also names the consumer of the index space (docs_batch_update) so the agent knows the handoff path.

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.