gdocs-mcp

Set this project’s default account/folder

set_project_default

Sets a project’s default Google account and/or Drive folder by writing or updating .gdocs-mcp.json, so new docs created by write_doc go to the intended location.

Instructions

Write this project’s defaults to a .gdocs-mcp.json in the current working directory (or update an existing one up the tree). Set a default account and/or a default folder (URL or id). The folder is where write_doc is told new docs go: a new doc given as a bare name or at the top of My Drive is refused once, naming the folder and the full path to call. It is read when the server starts, so write_doc’s description shows a change after a restart; the refusal reads it fresh. To set a folder by name, find it first with drive({ cmd: 'find' }) and pass its id.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "set_project_default"
  }
}

Input Schema

Name	Required	Description	Default
`folder`	No	default Drive folder (URL or id): where write_doc says a bare-named new doc will go
`account`	No	default Google account email (must be authorized)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.0.0Oct 31, 2026

changedInput schema / properties / folder / description

Previous value: -"default Drive folder (URL or id) for new docs"New value: +"default Drive folder (URL or id): where write_doc says a bare-named new doc will go"

First observedv0.1.1Aug 1, 2026

TDQS

A4.5/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 well: it discloses the on-disk side effect (writes/updates `.gdocs-mcp.json` up the tree), the restart semantics for write_doc's description versus the freshly-read refusal path, and the auth requirement on the account field. That is exactly the behavioral context an agent needs before mutating project state.

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: the write target and file location come first, then behavior, then the how-to. It is dense and mostly earns its space, though the sentence about restart versus fresh-read refusal is tangled and takes a second pass to parse.

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 two-parameter mutation tool with no annotations and no output schema, the description covers file location, side effects, downstream behavior in write_doc, and the id-lookup workaround. Only the response shape (confirmation of what was written) is left implicit, which is a minor gap.

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. The description adds genuine meaning beyond the schema: folder accepts a URL or id, either parameter alone is sufficient ("and/or"), and a folder given by name must first be resolved to an id via drive({ cmd: 'find' }).

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 concrete verb+resource: it writes the project's defaults to a `.gdocs-mcp.json` file in the cwd or an existing one up the tree. It names exactly what is being set (default account and/or default folder) and how that differs from siblings like get_project_config and set_page_setup.

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 states when the setting takes effect and how to resolve a folder given only a name (use drive({ cmd: 'find' }) and pass the id). It doesn't explicitly contrast with get_project_config for reading, but the usage context is otherwise unambiguous.

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