Google Workspace MCP Server - Control Gmail, Calendar, Docs, Sheets, Slides, Chat, Forms & Drive

Get Page

get_page

Read-onlyIdempotent

Retrieve details about a specific slide or page in a Google Slides presentation by presentation ID and page object ID.

Instructions

Get details about a specific page (slide) in a presentation.

Input Schema

TableJSON Schema

Name	Required	Description
`raw`	No	Return the complete Slides API Page resource as JSON instead of the summary. Nothing is filtered. Use when the summary does not carry a field you need. Overrides the other flags.
`include_styles`	No	Also report text styling: per paragraph (alignment, indents, spacing, bullets) and per run of uniform style (font family, weight, size, bold/italic, color), each with a short excerpt; plus placeholder linkage, autofit, fill and outline for shapes (fill=none / outline=none when explicitly not rendered), and the text styling of every table cell. Only explicitly set values appear; anything else is inherited from the placeholder named in the output. Use for proofing: font consistency, color use, alignment.
`page_object_id`	Yes	The object ID of the page/slide to retrieve.
`presentation_id`	Yes	The ID of the presentation.
`include_geometry`	No	Also report each element's placement - its transform (translate, and scale/shear when not identity) and intrinsic size, in raw EMU. Set this when adding elements to an existing deck: it is the only way to discover the deck's margins, gutters and content width, which Slides exposes nowhere else, and it reports the same terms batch_update_presentation writes. Defaults to False to keep the default output's token cost unchanged. Tables also report column widths, row heights and cell text.
`user_google_email`	Yes	The user's Google email address. Required.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.30.1Oct 3, 2026

changedInput schema / properties / include_geometry / description

Previous value: -"Also report each element's placement - its\ntransform (translate, and scale/shear when not identity) and intrinsic\nsize, in raw EMU. Set this when adding elements to an existing deck:\nit is the only way to discover the deck's margins, gutters and content\nwidth, which Slides exposes nowhere else, and it reports the same terms\nbatch_update_presentation writes. Defaults to False to keep the\ndefault output's token cost unchanged."New value: +"Also report each element's placement - its\ntransform (translate, and scale/shear when not identity) and intrinsic\nsize, in raw EMU. Set this when adding elements to an existing deck:\nit is the only way to discover the deck's margins, gutters and content\nwidth, which Slides exposes nowhere else, and it reports the same terms\nbatch_update_presentation writes. Defaults to False to keep the\ndefault output's token cost unchanged. Tables also report column\nwidths, row heights and cell text."

addedInput schema / properties / include_styles

Added value: +{
+  "default": false,
+  "description": "Also report text styling: per paragraph\n(alignment, indents, spacing, bullets) and per run of uniform style\n(font family, weight, size, bold/italic, color), each with a short\nexcerpt; plus placeholder linkage, autofit, fill and outline for\nshapes (fill=none / outline=none when explicitly not rendered),\nand the text styling of every table cell. Only explicitly set\nvalues appear; anything else is inherited from the placeholder\nnamed in the output. Use for proofing: font consistency, color\nuse, alignment.",
+  "type": "boolean"
+}

addedInput schema / properties / raw

Added value: +{
+  "default": false,
+  "description": "Return the complete Slides API Page resource as JSON instead\nof the summary. Nothing is filtered. Use when the summary does not\ncarry a field you need. Overrides the other flags.",
+  "type": "boolean"
+}

Changed1 schema field changedv1.26.0Sep 6, 2026

addedInput schema / properties / include_geometry

Added value: +{
+  "default": false,
+  "description": "Also report each element's placement - its\ntransform (translate, and scale/shear when not identity) and intrinsic\nsize, in raw EMU. Set this when adding elements to an existing deck:\nit is the only way to discover the deck's margins, gutters and content\nwidth, which Slides exposes nowhere else, and it reports the same terms\nbatch_update_presentation writes. Defaults to False to keep the\ndefault output's token cost unchanged.",
+  "type": "boolean"
+}

Addedv1.0.1Jul 31, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered structurally. The description adds nothing behavioral: it does not mention that output shape varies dramatically with raw/include_styles/include_geometry, nor the token-cost implications of those flags. With full annotation coverage the bar is lower, but a bare restatement earns only a 2.

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?

A single front-loaded sentence with zero padding, and the '(slide)' clarification is the one piece of information it needs to convey. It is efficient, though its brevity is close to under-specification rather than true conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, and the input schema is fully documented. Still, for a tool sitting next to get_presentation and get_page_thumbnail, the lack of any routing or prerequisite context leaves a real gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the flag parameters (raw, include_styles, include_geometry) have detailed, high-quality docs, so the schema does the heavy lifting. The description adds no parameter meaning beyond that, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get details about a specific page (slide)') and clarifies that 'page' means a slide, which is genuinely useful terminology mapping. However, it never distinguishes itself from siblings like get_presentation or get_page_thumbnail, so an agent must infer the boundary.

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

Usage Guidelines2/5

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

There is no when-to-use guidance and no mention of alternatives. An agent cannot tell from the description whether to call this, get_presentation, or get_page_thumbnail for a given need, nor that it requires an existing page_object_id from another call.

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

Deploy Server