verified-googledocs-mcp

export_pdf

Export a full Google Docs document as a PDF to a local file, returning page count, checksum, and path. Solves the need for an on-disk PDF copy or render-measured page count to verify page limits.

Instructions

Export the whole document as a PDF to a local path.

Use this tool when a caller needs a render-measured page count to check against a page limit, or simply needs a PDF copy on disk. Drive's export is doc-level, not tab-scoped, so this exports every tab in the document, not just one.

output_path must fall inside VERIFIED_GOOGLEDOCS_MCP_ALLOWED_FILE_ROOTS (defaults to the user's home directory) and must never resolve to a credential path; its parent directory must already exist. page_count is best-effort and is None when the PDF hides its page markers inside a compressed stream — never a guessed number. Drive refuses exports whose PDF would exceed roughly 10 MB.

This is a read/export tool: nothing in the document changes, so the return value has no "applied" key. Returns doc_id, output_path, bytes_written, sha256, page_count, existed_before, audit_logged.

Errors: INVALID_INPUT – a bad output_path (missing parent directory, outside the allowed roots, a denylisted credential path, or an existing target that isn't a regular file), or Drive refused the export (not found, permission denied, or the size limit) AUTH_EXPIRED – no valid token

Input Schema

TableJSON Schema

Name	Required	Description	Default
`doc_id`	Yes
`output_path`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Sep 5, 2026

TDQS

A4.7/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 it excels: it states this is a read/export tool that changes nothing, page_count is best-effort and never guessed, Drive refuses exports over roughly 10 MB, and the return value has no 'applied' key. It also documents error categories and path restrictions.

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 detailed yet tightly organized. Each sentence adds operational value: use cases, scope, path constraints, page-count caveats, size limits, return fields, and errors. The error list at the end is structured and scannable.

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 minimal schema and annotations, the description covers invocation context, safety constraints, return semantics, and failure modes. It also names the exact return keys, so an agent knows what to expect even without relying on the output schema.

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 0%, so the description must compensate. It substantially explains output_path: must fall inside VERIFIED_GOOGLEDOCS_MCP_ALLOWED_FILE_ROOTS, must never resolve to a credential path, and its parent directory must already exist. doc_id is not explicitly described, but the tool name and 'whole document' phrasing make its role sufficiently clear.

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: 'Export the whole document as a PDF to a local path.' It further distinguishes itself from tab-scoped siblings by explicitly noting that Drive's export is doc-level and exports every tab, not just one.

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 gives explicit scenarios: use when a render-measured page count is needed or when a PDF copy on disk is required. It also clarifies the tool is doc-level rather than tab-scoped, which helps an agent avoid misusing it for single-tab exports, though it does not name specific sibling alternatives.

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