Google Workspace MCP

docs_create

Create a new Google Doc with a title and optional opening text. Generates a ready-to-use document directly from the agent for immediate editing.

Instructions

Create a new Google Doc with a title, and optionally an opening body of text.

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": {
      "title": "<title>"
    },
    "name": "docs_create"
  }
}

Input Schema

Name	Required	Description	Default
`text`	No
`title`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 1, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already communicate that this is a write operation that is not destructive. The description adds the useful nuance that the text parameter becomes the opening body of the document, but it does not disclose return value, location, or other side effects. No contradiction with annotations.

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?

A single sentence that front-loads the action and resource, then adds the only needed param context. No filler or repetition.

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 simple two-parameter creation tool, the input side is fully described and the optionality of body text is clear. The main minor gap is that the returned document ID is not mentioned, which could matter for chaining with docs_append or docs_get, but it is not needed to invoke the tool correctly.

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?

With 0% schema description coverage, the description carries the parameter-documentation burden. It names both params: title as the document title and text as an optional opening body, which adds real meaning beyond the bare schema.

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 states a specific verb and resource: 'Create a new Google Doc.' The word 'new' clearly distinguishes it from docs_append and docs_get, making the tool's purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly establishes that this is the creation entry point among the docs_* tools and indicates the optional input. It does not explicitly mention alternatives or when not to use it, but the name and sibling context make the intended use obvious.

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