Skip to main content
Glama
taylorwilsdon

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

by taylorwilsdon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Page

get_page
Read-onlyIdempotent

Retrieve detailed information about a specific slide, including its elements and optional geometry.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
page_object_idYesThe object ID of the page/slide to retrieve.
presentation_idYesThe ID of the presentation.
include_geometryNoAlso 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.
user_google_emailYesThe user's Google email address. Required.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.26.0
    • 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"
+}
  2. Addedv1.0.1

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is established. The description adds useful behavioral context via include_geometry: it explains that geometry output is in EMU, that it is needed for discovering deck margins/gutters, and that defaulting to false keeps token cost unchanged—information not present in 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The entire description is one focused sentence that states the action and object with no filler. It is front-loaded and easy 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 simple read-only tool, the definition is largely complete: annotations cover safety, the schema covers all parameters, and an output schema exists. The only gap is the lack of explicit guidance on when to choose get_page over get_presentation, though the description's 'specific page' phrasing implies it.

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%, so the baseline is 3. The tool description itself says nothing about parameters; all meaningful semantics live in the input schema, particularly the rich include_geometry explanation.

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?

Description clearly states a read operation on a specific page/slide within a presentation, with a direct object and scope. It differentiates from sibling get_presentation (whole deck) and get_page_thumbnail (thumbnail) by specifying details rather than thumbnail or full presentation.

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

Usage Guidelines3/5

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

The description does not name alternative tools or give exclusion conditions for when not to use it. The include_geometry parameter does offer conditional advice about when to enable geometry, but tool-selection guidance remains implied rather than explicit.

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

Deploy Server

Other Tools