A1 Google Slides MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools map cleanly to a distinct resource and action, and the descriptions are thorough enough to resolve most ambiguity. The text-related tools (insert_text, set_text, replace_text) and the two escape hatches (batch_update, raw_request) have partially overlapping purposes, so an agent could occasionally select the wrong one.
Naming Consistency4/5
The naming is consistently snake_case and mostly follows a verb_noun pattern such as create_presentation, list_slides, set_text, and update_transform. The main deviation is raw_request, which is an adjective_noun form rather than verb-first.
Tool Count3/5
At 26 tools, the surface is heavy and above the ideal MCP range, but the server covers a genuinely broad Google Slides API domain including slide management, elements, text, tables, notes, comments, export, and raw requests. The count is justified by the scope, though it still feels large.
Completeness5/5
The tool surface covers virtually the full presentation lifecycle: creating, reading, listing, editing, duplicating, moving, deleting, text manipulation, image/table operations, speaker notes, comments, thumbnails, and export. Missing operations like deleting the presentation file are explicitly outside the server's stated Drive scope, so there are no meaningful dead ends.
Average 4.6/5 across 26 of 26 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on August 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly discloses behaviors beyond the annotations: URL validation constraints, local file upload and subsequent Drive deletion, native proportion handling, point-based positioning, and the returned objectId. This is especially valuable because the annotations are sparse (readOnlyHint=false, destructiveHint=false). No contradiction with annotations exists.
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 dense but front-loaded with the core purpose, followed by essential constraints and side effects. Every sentence and parenthetical carries needed operational information; nothing is filler.
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?
For a 9-parameter tool with no output schema and minimal annotations, the description is thorough: it covers input validation, cleanup behavior, sizing defaults, coordinate units, and the return value. An agent has enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant meaning by specifying validation limits (https-only, no private hosts, ≤2 kB URL; PNG/JPEG/GIF ≤50 MB, ≤25 megapixels), the disposable temp-file lifecycle, and how omitted size parameters behave. This goes well beyond the schema's basic field descriptions.
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?
The description clearly states a specific action ('Inserts an image on a slide') and identifies the underlying operation (batchUpdate createImage). It does not explicitly distinguish this from the sibling replace_image tool, so it lacks the full sibling-differentiation that would earn a 5.
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?
The description explains the two mutually exclusive input modes (image_url or image_path) but gives no guidance about when to prefer this tool over alternatives such as replace_image or batch_update. There is no explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description reveals subtle behavior: insertion_index is evaluated before the move, and the moving-down example clarifies how indices are counted. This is valuable context that the annotation fields do not provide. It does not mention error behavior or response format, but the disclosed semantics are the most important part.
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?
Three concise sentences cover the action, the critical constraints, and the recommended precursor step. The most important detail is front-loaded, and there is no filler or redundant elaboration.
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 mutation tool with three required parameters and no output schema, the description covers the essential call semantics, ordering constraints, and the need to check current order first. It could mention failure cases such as invalid or missing slide IDs, but the provided guidance is sufficient for a correct invocation in most cases.
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 meaning by emphasizing that slide_object_ids must contain no duplicates and by explaining the insertion_index behavior with a concrete moving-down example. This goes slightly beyond simply restating the 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: 'Moves one or more slides to a new position.' It also names the underlying API operation (batchUpdate updateSlidesPosition), which clearly distinguishes it from sibling tools like add_slide, duplicate_slide, and delete_object.
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?
The description gives practical guidance on preconditions: 'Use list_slides to see the current order first.' It also explains the required ordering and duplicate constraints. It does not explicitly contrast this tool with alternatives, but the purpose is clear enough that an agent can infer when reordering is the right operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the readOnly/destructive/idempotent flags, so the bar is lower. The description adds genuine context beyond them: it specifies what is preserved (frame, position, effects), what effect each replace_method has on the bitmap (center_inside scales to fit keeping aspect; center_crop fills and crops overflow), and that upload/cleanup behavior matches create_image. This meaningfully clarifies what the destructiveHint implies.
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?
Three sentences with no filler: the first states the core action and preserved attributes, the second bounds the input sources with a cross-reference, and the third defines the enum semantics. The most decision-relevant information (what is swapped, what is kept) is front-loaded.
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 5-parameter mutation tool with no output schema, the description covers the core behavior, preserved properties, input-source constraints, and method semantics. The only gap is that it doesn't describe the response shape or error conditions, but since the operation is a straightforward bitmap swap and the schema documents required params, this is a minor omission rather than a blocking one.
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 value beyond the schema by explaining the behavioral difference between the two replace_method enum values (scale-to-fit vs. crop-overflow) and by clarifying that image_url/image_path inherit exactly the same validation, upload and cleanup rules as create_image, which the schema's 'exactly one of' constraint alone does not convey.
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 ('Swaps') and resource ('bitmap of an existing image element') and names the underlying API (batchUpdate replaceImage). It also distinguishes itself from create_image by stating it preserves frame, position and effects, which is exactly what separates this sibling from create_image in the sibling list.
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?
The first sentence implies the use case: replace an existing image while keeping its frame/position/effects, and the cross-reference to create_image's validation/upload/cleanup rules gives the agent a known behavioral contract. However, it never explicitly states when not to use this tool or names an alternative approach (e.g., delete_object + create_image), so it lacks the explicit exclusions needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the destructive/non-read-only profile; the description adds the atomic batch behavior (one invalid request rejects everything), the verbatim wire-format expectation, and wire conventions for lengths/coordinates and enums. This goes beyond annotations without contradicting them.
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?
The description is longer than a typical tool because it maps the raw request union, but every sentence carries load and the core purpose is front-loaded. The long operation list could arguably be compressed with an API link, which keeps it from a 5.
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 raw, open-ended API tool with no output schema, the description provides the key invocation information: request shape, example, units, enums, and atomicity. It does not describe the success response shape, but that is not necessary for selecting or constructing the call and 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% for the two parameters, so the baseline is 3. The description adds real value with a concrete JSON example for requests, explains 'verbatim wire format,' and specifies units ('PT') and UPPER_CASE enums, none of which are in the 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 opens with a specific verb and resource: 'Sends raw Slides API batchUpdate requests.' It scopes the tool to 'anything the typed tools don't cover' and enumerates request types, clearly distinguishing it from the typed sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly positions the tool as the fallback for anything the typed tools don't cover, so an agent knows to prefer a typed sibling when one exists. The listed operations and openWorldHint reinforce when this raw request path is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate a non-read-only, non-idempotent write operation. The description adds valuable behavioral context: the table is empty at creation, the API returns an objectId, omitted geometry results in a centered default, and position/size are measured in points. This goes beyond the annotations without contradicting them.
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 compact and front-loaded: the main action and return value appear first, followed by related tool usage, geometry behavior, and styling guidance. Every sentence adds useful information without redundancy or filler.
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?
For a create operation with no output schema, the description covers the essential return value (objectId) and the resulting table state (empty, sized rows/columns). It also gives enough context for follow-up operations, making it complete for an agent to invoke and continue working with the created table.
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 meaningful semantics on top: it clarifies that geometry uses points and that omitting geometry lets the API choose a centered default. It also confirms that row and column indexes used later for filling cells are 0-based, which helps agents use downstream tools correctly.
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 clearly states the tool's action: it creates an empty rows x columns table on a slide and returns its objectId. It also distinguishes table creation from sibling tools by explicitly routing cell-filling and restructuring to set_text/insert_text and edit_table, so there is no ambiguity about what this specific tool does.
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?
The description provides clear workflow guidance: use this to create the table, then fill cells with set_text/insert_text, restructure with edit_table, and style cells via batch_update. It does not explicitly state conditions for when not to use it, but it gives enough context for an agent to choose the right tool in a multi-step table operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, and the description adds valuable consequences: deleting a slide removes its elements and speaker notes, deleting a group removes children, and there is no API-level undo. This goes well beyond the annotations and prepares the agent for irreversible side effects.
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?
Three sentences, each earning its place: the core action, the destructive side effects, and the key limitation. The main behavior is front-loaded and the caveats are concise.
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?
For a destructive single-object deletion tool, the description covers the operation, side-effect cascading, irreversibility, and an important boundary (cannot delete the whole presentation). Combined with full schema coverage and destructiveHint, this is complete enough for an agent to call safely and interpret behavior.
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 input schema already documents both presentation_id and object_id, including where each comes from. The description does not add much parameter-specific meaning beyond saying deletion is by object id, so baseline 3 is appropriate.
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?
States a specific verb and resource: deletes a slide or page element by object id. It also explicitly scopes what it cannot do (delete the whole presentation), which helps distinguish this tool from Drive-level operations.
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?
Clearly frames when the tool is appropriate: deleting a slide or element by object id. It also gives an explicit exclusion for whole-presentation deletion. However, it does not directly discuss when to prefer batch_update for multiple deletions or other combined operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details beyond the annotations: the copy includes all elements and speaker notes, lands immediately after the original, works for page elements with a slight offset, and returns the new objectId. This is exactly the side-effect and response information an agent needs, and it does not contradict the readOnly/idempotent 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?
Three focused sentences front-load the action and then add placement, return-value, and follow-up guidance. Every sentence carries useful information with no filler or repetition of schema content.
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?
The description covers the operation's behavior, result position, returned value, and even the page-element edge case. Given that there is no output schema, mentioning that the new objectId comes back in the reply is especially valuable, making the definition complete for an agent to invoke correctly.
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 coverage is 100% and both parameters already have clear descriptions, so the baseline is 3. The description's mention of page-element support is already present in the slide_object_id schema description, and the 'new objectId' detail concerns the response rather than the parameters.
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: 'Duplicates a slide.' It further disambiguates by noting it wraps batchUpdate duplicateObject and extends to 'any page element id,' which clearly distinguishes it from add_slide and other slide-creation tools.
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?
The description gives clear usage context: the duplicate lands immediately after the original and can be repositioned with move_slides afterwards. It names a sibling tool as a follow-up, but it does not explicitly explain when to prefer duplicate_slide over add_slide or another alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and idempotentHint=true, so the description's main addition is contextual: it clarifies that the tool 'only reads what the deck already has' and that the API cannot alter theme/master sets. This is useful beyond the annotations, though it does not discuss error or edge-case behavior.
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?
Two sentences pack all essential information with no filler. The returned structure is front-loaded, and the usage constraint is integrated without bloat.
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?
For a simple read-only tool with one fully documented parameter and rich annotations, the description is complete: it names the return fields, explains how the output is used, and sets expectations about API limitations. No output schema exists, but none is needed here because the description covers the core return shape.
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?
The single parameter presentation_id is already fully described in the schema with a clear example URL and source. The description adds no new parameter-level meaning, so the baseline of 3 for high schema coverage is appropriate.
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 names a specific verb ('Lists') and a specific resource ('the presentation's theme building blocks'), then enumerates the exact returned components: layouts[], masters[], and notesMasterObjectId. This clearly distinguishes it from sibling tools like list_slides and get_presentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains a concrete use case: layout object ids feed add_slide's layout_object_id. It also provides an explicit exclusion — the Slides API cannot import a new theme or change the master set, and themes are chosen in the UI — which tells an agent when not to attempt a mutation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral context on top: it returns a compact inventory, truncates visible text to 160 chars, and enumerates the exact shape of the returned data. This goes beyond the annotations without contradicting them.
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?
Two dense sentences pack in the return payload, the primary use case, the relationship to mutation tools, and the boundary with sibling tools. Nothing is wasted, and the key idea 'compact inventory' plus 'read to start from' is front-loaded.
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?
There is no output schema, so the description carries the burden of explaining return values. It enumerates presentationId, title, revisionId, pageSizePt, slideCount, and per-slide fields including elements, which is sufficient for an agent to know what to expect. Combined with guidance on when to call it and when to use alternatives, the contextual picture is complete.
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?
The schema is fully self-sufficient: presentation_id is described with its source (URL or create_presentation output) and minLength validation. The description does not need to add parameter-level detail, and the baseline of 3 applies because the schema covers 100% of parameter semantics.
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 is explicit: it is a compact inventory (read-only overview) of the deck, listing exactly which presentation-level and slide-level fields are returned. It also distinguishes itself from get_presentation and get_page by noting those are needed for full text and geometry. This makes the tool's purpose unambiguous and separates it from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage direction: 'the read to start from' and 'call this before editing' because mutation tools reference the object ids it returns. It also names the alternatives (get_presentation/get_page) for deeper per-element data, so an agent knows when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description meaningfully supplements the annotations by explaining mutational scope: it touches shapes, table cells, and speaker notes; matching is literal, case-sensitive by default; and it returns occurrencesChanged, with 0 indicating no match and a suggestion to verify via list_slides. This goes well beyond the readOnly/destructive/idempotent hints and compensates for the missing output schema.
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?
Four tightly packed sentences, no filler. The main purpose is front-loaded, and subsequent sentences each add a distinct useful trait: scope, matching semantics, return-value interpretation, and a concrete workflow.
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?
For a mutating, whole-deck operation with no output schema, the description covers scope, matching constraints, case sensitivity, scoping to specific slides, return-value semantics, and the canonical template workflow. It leaves no practical gap an agent would need to call it correctly.
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 coverage is 100%, so the baseline is 3. The description adds a few clarifications like match_case=false to ignore case and using page_object_ids to scope, but these largely restate what the schema already provides. It does not add substantial new parameter meaning beyond the existing descriptions.
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: 'Finds and replaces every occurrence of a string across the whole deck' and enumerates exactly what is affected (shapes, table cells, speaker notes). This clearly distinguishes it from sibling text tools like insert_text or set_text, which target individual insertions or specific text frames.
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 clear context: use it for whole-deck replacement, scope with page_object_ids for selected slides, and it explicitly calls out the classic template placeholder flow. It does not explicitly contrast with alternative text-editing siblings, but the scope and use case are clear enough for an agent to select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior beyond the annotations: it reveals that the notes object id is resolved internally, that the rewrite is atomic, that an empty string clears notes, and that notes appear in presenter view and txt exports. No contradiction with readOnlyHint=false or destructiveHint=true exists.
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 two sentences with no filler. It front-loads the core action, then packs essential clarifications (empty string behavior, internal resolution, object id distinction, paragraph syntax, and export visibility) into a tight, readable structure.
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?
For a three-parameter mutation tool with no output schema, the description covers the action, the special object-id semantics, clearing behavior, idempotent atomic rewrite, and downstream visibility/export implications. Nothing essential for invoking the tool correctly is missing.
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?
The input schema already provides 100% parameter documentation, including that slide_object_id is 'not the notes page id' and that text supports \n. The description reinforces these points but adds limited new parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.
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: 'Replaces a slide's speaker notes with the given text.' It also clarifies the exact scope (speaker notes, not slide content) and differentiates from siblings like get_speaker_notes and set_text by emphasizing the notes-specific target and internal object resolution.
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?
The description gives clear context for use: pass the slide object id, not the notes shape id, and use \n for paragraphs. It also clarifies behavior for empty strings. However, it does not explicitly name alternatives or state when not to use this tool versus other text-editing or notes-reading siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true), and the description adds genuinely useful behavioral context: only supplied fields are changed due to the automatic field mask, at least one field is required, offset indexing is end-exclusive, and offsets come from get_page. This does not contradict 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 description uses four tight sentences: one for purpose/properties, one for mutation scope, one for range offsets, and one for table cells. There is no filler, and the essential field-mask and at-least-one-field constraints are front-loaded.
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?
For a complex 14-parameter mutation with no output schema, the combination of this description and the 100%-coverage input schema tells the agent what to pass, how ranges work, when table-cell indices are needed, and where to look up offsets. Nothing critical to invoking it correctly is missing.
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?
Because schema description coverage is 100%, the baseline is 3; the description goes further by explaining the automatic field-mask behavior, requiring at least one style field, and clarifying that start_index/end_index and row_index/column_index must be paired. Those semantics are not fully inferable from individual schema descriptions.
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 starts with a precise verb and resource: 'Styles the text of a shape or table cell', and identifies the underlying API operation (batchUpdate updateTextStyle). It enumerates the style traits, making it immediately distinguishable from sibling content tools such as set_text, insert_text, and replace_text.
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 clear call conditions: style a whole text object by default, style a range with start_index/end_index, and style a table cell by adding row_index/column_index. It also points to get_page for offsets, but it never explicitly states when not to use this tool or contrasts it with the sibling text-content tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations: it discloses permanent deletion, the inability to anchor new comments, pagination behavior, tombstone handling, resolve semantics, and the OAuth scope requirement with a concrete 403 failure mode. These are behaviors the agent cannot infer from the schema or annotations alone.
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?
The description is dense but every sentence contributes actionable detail. It is structured as a single paragraph with semicolon-separated action clauses, which is readable though slightly run-on; it front-loads the core purpose before diving into per-action specifics.
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 tool with no output schema, the description covers the critical input-side context: each action's parameters, pagination, auth requirements, and destructive behavior. It does not describe the exact response format for get/list, but for selecting and invoking the tool correctly, the missing return details are a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds crucial cross-parameter semantics: which parameters apply to which actions, that content must be plain text, that resolve only makes sense with reply, and that comment_id comes from list results. This bridges the flat schema into per-action usage rules.
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 names the resource ('comment threads on the presentation file') and the specific actions ('list', 'get', 'create', 'reply', 'delete'), making the tool's purpose unmistakable. It also distinguishes itself from generic Drive access and from sibling tools that manipulate slides, shapes, or text.
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?
The description gives clear action-by-action usage conditions, including required parameters and caveats such as 'create ... starts a new unanchored thread' and 'delete ... permanently removes the thread'. It does not explicitly name an alternative sibling tool, but none exists for comments, and the 'scoped to this one file' note helps prevent misuse of the underlying Drive API.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses meaningful side effects: a file is created in the authorized user's Drive, the deck starts with one title slide, and the return payload includes presentationId, revisionId, pageSize, and object ids. It also reveals a limitation: this server cannot delete a presentation. These details add substantial behavioral context and do not contradict 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 description is front-loaded with the core purpose and return value, then adds only high-value operational caveats. Every sentence earns its place, including the sibling-tool routing and the deletion limitation, with no filler or repetition.
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?
With no output schema, the description compensates by enumerating the returned fields (presentationId, revisionId, pageSize, initial title slide with object ids, layouts, masters). It also covers initial deck state, ownership, and deletion limitations, making the tool fully understandable for an agent to invoke correctly.
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 single title parameter is already described as 'The presentation title (also the Drive file name).' The tool description adds the contextual note that only the title is honored at creation, but it does not provide additional parameter-level format, constraints, or examples beyond what the schema already gives.
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 begins with a specific verb and resource: 'Creates a new Google Slides presentation and returns it.' It also clearly differentiates this tool from content-editing siblings by stating that slides and content must be added with add_slide and the text/shape/table/image tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states what this tool is for and what it is not for: it honors only the title at creation, so agents should use add_slide for slides and dedicated content tools for content. It also clarifies that deletion is a Drive operation outside this server's scope, giving concrete when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds useful behavioral detail beyond annotations: the response includes slideProperties.notesPage, pageElement size, transform in EMU units with conversion, and complete text. This helps the agent anticipate the return shape even without an output schema.
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?
Three sentences with no filler: the first states the core action and scope, the second gives the most important return-shape details, and the third routes the agent to the right alternative. Key information is front-loaded.
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?
For a simple two-parameter read-only tool, the description covers the purpose, valid inputs, alternative tools, and the essential response contents. The lack of an output schema is compensated by the explicit description of notesPage, pageElements, size, transform, and text.
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, but the description adds meaningful context by clarifying which object ids are valid (slide/layout/master/notes-page id from list_slides or get_presentation) and by explaining the EMU transform unit. These details reinforce the schema without contradicting it.
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?
States a specific verb and resource ('Returns one page in full by its object id') and explicitly enumerates supported page types: slides, layouts, masters, and notes pages. It also differentiates itself from siblings by naming list_slides and get_presentation as alternatives, so an agent can disambiguate without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use guidance: use it when a single page needs full detail and list_slides' summary is insufficient, but get_presentation would return too much. It also establishes which page object ids are valid, effectively excluding irrelevant inputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds meaningful behavioral context: returns plain text plus an object id, treats an empty string as 'no notes yet', and hides the notes-page lookup. This tells the agent exactly what to expect from the call.
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?
Four sentences, each carrying distinct information: return value, lookup simplification, empty-string semantics, and integration with replace_text. There is no filler, repetition, or unnecessary detail.
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?
For a simple read-only two-parameter tool with no output schema, the description fully covers what the agent needs: how to obtain the required id, what the response contains, and what empty results mean. No significant gaps remain.
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 schema already documents both parameters well. The description adds value by reinforcing that slide_object_id is the slide id from list_slides—not the notes page id—and explaining why that single id is sufficient because the lookup happens internally. This is a small but useful semantic addition.
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 ('Returns') and identifies the exact resource: a slide's speaker notes as plain text, plus the speakerNotesObjectId. It also clarifies that the notes page is hidden and fetched internally, which clearly distinguishes this from siblings like set_speaker_notes and get_page.
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?
The description gives clear context: the caller only needs slide_object_id from list_slides because the notes page is fetched internally, and it notes that replace_text also searches notes text. It does not explicitly spell out when not to use this tool versus set_speaker_notes, but the read/write contrast and the 'only need' guidance make correct routing straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the annotations: the two output modes (contentUrl vs local file), the short-lived URL (~30 minutes), the restriction to Google's image hosts, size options with pixel dimensions, and the quota cost. This is exactly the kind of context an agent needs to predict runtime behavior.
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 compact and front-loaded: the first sentence states the core purpose, followed by behavior, size, and usage context. Every sentence earns its place with dense, useful information and no filler or repetition.
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?
There is no output schema, so the description correctly explains return behavior ('returns contentUrl + width/height') and the local-file alternative. It also covers URL expiry, download restrictions, size defaults, and quota impact, giving an agent everything needed to call it 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?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantic value by stating the default size ('large (1600px, default)') and clarifying the behavior of output_path (omitted = returns contentUrl; provided = downloads to local file), which goes beyond the schema's individual parameter descriptions.
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 names a specific verb ('Renders') and a clear resource ('one page (slide, layout or master) as a PNG'), and immediately differentiates this tool from JSON-based alternatives by stating 'the JSON never shows rendering.' This makes the tool's purpose unambiguous.
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 to use the tool: 'This is the way to SEE what a slide actually looks like — the JSON never shows rendering.' It also warns that it 'Counts as an expensive read in the API quota,' implying it should be used judiciously. However, it does not explicitly name sibling tools like get_page, so the routing is slightly less direct than a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses meaningful behavioral traits beyond the annotations: the operation is one atomic deleteText(ALL)+insertText batch, the delete is skipped for empty targets, an empty text clears the object, and per-character styling is dropped. These are exactly the side effects an agent needs to anticipate.
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?
Every sentence has a purpose: core behavior, edge-case handling, clearing semantics, styling consequence, and table-cell parameter guidance. It is front-loaded with the most important fact and contains no filler.
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?
For a mutation tool with no output schema, the description covers target types, required table parameters, empty-input behavior, atomicity, and styling side effects. The idempotency hint and destructive hint are already in annotations, so no critical gap remains.
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, but the description adds value by clarifying that object_id refers to a shape or table cell, that row_index and column_index must be supplied together, and that an empty text string clears the object.
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 precise verb and resource: 'Replaces the ENTIRE text of a shape or table cell'. It distinguishes the tool from siblings like insert_text or replace_text by emphasizing whole-content replacement rather than partial insertion or search-based replacement.
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?
The description clearly implies when to use it — when the entire text must be replaced — and explicitly tells the agent to pass row_index plus column_index together for table cells. It also points to update_text_style as the follow-up for restyling, but does not explicitly contrast with insert_text or replace_text, so it lacks direct exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral detail beyond the annotations: it reveals the underlying batchUpdate createSlide call, the returned objectId, the default layout behavior when neither layout option is provided, and that inherited placeholders arrive empty. This gives the agent a realistic model of side effects without contradicting the readOnly=false, destructiveHint=false, or openWorldHint=true 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 description is dense but every sentence earns its place: main action and return, layout selection options with the mutual-exclusion rule, insertion position semantics, and the downstream placeholder workflow. It is front-loaded with the most decision-relevant information and contains no filler.
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?
For a 5-parameter tool with no output schema, the description covers all parameter choices, return behavior, default behavior, and the natural follow-up actions. The agent has enough information to call the tool correctly and knows what to expect in the reply, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though the schema already describes all parameters at 100% coverage, the description adds crucial relationship semantics: predefined_layout and layout_object_id are mutually exclusive, omitting both copies the last slide's layout, and insertion_index is 0-based with omission meaning append. This is precisely the kind of inter-parameter meaning the schema alone does not convey.
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: 'Adds a slide (batchUpdate createSlide)' and states the key return value, the new slide's objectId. It distinguishes the tool from siblings like duplicate_slide and delete_object by focusing on creating a fresh slide from a layout or copying the current last slide's layout.
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?
The description gives clear context for when to use this tool—when adding a new slide—and explains how to choose a layout via predefined_layout or layout_object_id from list_layouts, including the 'not both' exclusion. It does not explicitly name sibling alternatives like duplicate_slide, but it does route subsequent actions to list_slides and set_text, giving the agent a clear workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructive, not read-only, not idempotent), the description adds critical behavioral context: deletion permanently discards cell content and remaining rows/columns shift, changing indexes between successive edits. This is exactly the kind of non-obvious side effect an agent needs to know.
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 dense but every clause earns its place: purpose, per-action parameter mapping, defaults, destructive consequences, index-shift caveat, and the explicit alternative for text edits. It is one well-structured paragraph with no filler.
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 complex 8-parameter tool with no output schema, the description covers the action-specific parameter combinations, defaults, destructive behavior, and exclusions. The only minor gap is that it does not describe what the operation returns or what success looks like, though this does not block correct invocation.
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 value above the schema by mapping each action to its applicable parameters (row_index/column_index, below/right, count) and clarifying defaults and the 1-20 count range in context. It does not merely repeat schema text.
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 clearly states the tool 'Restructures an existing table in one call' and enumerates the four exact structural actions it supports. It also explicitely distinguishes itself from set_text/insert_text by stating cell text is not written here, so an agent can tell it apart from the text-editing siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this tool for structural edits and when not to use it, pointing to set_text/insert_text for cell text. It also warns that indexes shift between successive edits and tells the agent to re-check with list_slides, which is clear operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses the 10MB export cap, the required Drive scope, the returned fields (saved_to, bytes, mime_type), and that nothing in the presentation changes. The local-file overwrite is disclosed, while destructiveHint=false remains consistent with the source resource, so no annotation contradiction exists.
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 three sentences with no filler: the first sentence states the core action, the second covers limits and failure handling, and the third covers auth and return contract. Each sentence earns its place.
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?
For a tool with no output schema, the description fully specifies what the agent gets back (saved_to, bytes, mime_type) and the side effects (file written, presentation unchanged). Combined with the detailed schema and annotations, nothing essential is missing.
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 description coverage is 100%, so the baseline is 3. The description adds value by clarifying that txt means all text including speaker notes, and it confirms the overwrite behavior on output_path. This extra meaning justifies a 4.
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 uses a specific verb ('Downloads ... and saves it to output_path'), names the resource (the whole presentation), and lists all supported formats. This clearly identifies export_presentation as the file-export tool among the siblings, which otherwise perform edits, reads, or raw requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when the tool fails (decks over 10MB) and offers the alternative of splitting the deck or using the Slides UI. It also gives an OAuth prerequisite and its failure mode (403 with presentations-only scope). This is actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses that responses can be hundreds of kilobytes, advises trimming with a fields mask, and explains the EMU unit for pageSize. These are useful behavioral warnings that an agent cannot infer from the schema or annotations alone.
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 compact and front-loaded: it states the return value first, then the key content, then the warning and usage tip. Every sentence serves a purpose and no filler or repetition exists.
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?
With no output schema present, the description carries the full burden of explaining return shape and behavior. It covers the main response components, units, size risks, and how to constrain the response. For a read-only retrieval tool, this is complete enough for an agent to invoke it 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?
The schema already documents both parameters at 100% coverage, so the baseline is 3. The description adds value by explaining why fields matters ('full deck is often hundreds of kilobytes'), giving a richer example of a fields mask than the schema does, and situating fields as the trimming mechanism when raw detail is desired.
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 clearly states the tool's behavior: it returns the raw presentation JSON, and enumerates the key resources inside it (slides, layouts, masters, notesMaster, pageSize, revisionId). This distinguishes it from siblings like list_slides and get_page by emphasizing 'raw' and 'every page element'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: prefer list_slides for an inventory, and use this tool with a fields mask when raw detail is needed. This names the alternative and provides a concrete condition for choosing this tool over it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly=false, destructive=false), the description discloses insertion semantics, newline-to-paragraph behavior, table-cell coordinate requirements, and target restrictions. This is exactly the kind of behavioral context the schema and annotations do not carry.
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?
Four tightly written sentences pack the essential behavior, target constraints, table-cell handling, and sibling routing with zero filler. The main action is front-loaded, and each sentence earns its place.
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?
For a mutating tool with no output schema, the description covers operation semantics, target validity, coordinate pairing, placeholder use, and the alternative for replacement. An agent has enough to decide whether and how to invoke this 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?
Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying that row_index and column_index must be used together, that insertion_index defaults to the beginning, and that the object must be a text-capable shape or table — details that enrich the schema without repeating it verbatim.
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?
States a specific verb ('inserts text'), the resource ('shape or table cell'), and the key positional behavior (0-based index, default 0). It explicitly differentiates from set_text, making the tool's purpose unmistakable even among the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names the alternative (set_text) for replacement, gives a positive use case (filling empty layout placeholders), and states the target constraint (shapes with text or tables, not images/lines). Clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantive behavioral context beyond the annotations: the Bearer token is added automatically, paths resolving to foreign origins are rejected, and Drive endpoints are unreachable. It also notes the API only has GET and POST endpoints. These details help an agent predict consequences when invoking this open-world, potentially destructive tool.
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 dense but every sentence contributes: it establishes the purpose, gives concrete examples, states constraints, and points to alternatives. The most important information is front-loaded, and there is no filler or repetition of schema content.
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?
For an open-world raw request tool with no output schema, the description covers nearly everything an agent needs: the base URL, authentication behavior, method restrictions, path rules, and explicit boundaries around other API domains. The absence of a return-value explanation is acceptable because the raw response is inherently unpredictable and the tool is designed as an escape hatch.
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?
The schema covers 100% of parameters, so the baseline is 3. The description adds extra meaning by clarifying that the path is relative to https://slides.googleapis.com, may include a query string, and that the body is JSON only for POST. This supplements the schema examples with operational context, though not dramatically.
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 clearly identifies the tool as an escape hatch to call any Google Slides API v1 path directly, with a specific verb and resource. It differentiates itself from the typed siblings by explicitly covering requests batch_update doesn't handle and excluding Drive endpoints. An agent can immediately understand what this tool is for and how it differs from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: use it when batch_update or typed tools don't cover the request, and use manage_comments or export_presentation for Drive endpoints. It also clarifies that only GET and POST are valid methods. This is direct, actionable routing information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing that the operation is atomic, that omitted geometry defaults to 300x80 pt at (50,50), that coordinates are in points with (0,0) at top-left, and that the reply returns the shape's objectId. It also explicitly states what is not a parameter here, preventing misuse. No contradiction with annotations was found.
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 compact yet information-dense, with no filler phrases. It front-loads the core action and then efficiently packs supported types, exclusions, geometry defaults, return value, and sibling alternatives into a few sentences.
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?
For a 9-parameter tool with no output schema, the description provides all essential context: supported types, coordinate and default behavior, return value, and explicit direction to sibling tools for unsupported operations. An agent has enough information to invoke this tool correctly without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant meaning: it explains the coordinate system, default slide dimensions, default geometry, and how the text parameter is inserted in the same atomic batch. It also enumerates the allowed shape types, reinforcing the enum and clarifying scope beyond the 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: 'Creates a shape on a slide (batchUpdate createShape)', and clearly distinguishes this tool from batch_update by listing the supported ShapeTypes and explicitly routing the other ~130 types elsewhere. The mention of optional initial text in the same atomic batch further refines the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-not guidance: unsupported shape types go through batch_update, and fill/outline/shadow styling goes through batch_update updateShapeProperties while text styling goes through update_text_style. This tells the agent exactly which sibling to choose for related but different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by detailing side effects: absolute mode replaces the entire transform and omitted scales default to 1, not current values; relative mode multiplies onto existing transform and scaling around origin shifts the element. It also notes where to find geometry (get_page). No contradiction with annotations (destructiveHint=true is consistent with 'REPLACES the whole transform'). This is exactly the kind of behavioral context agents need.
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 dense but every sentence is purposeful. It front-loads the key action and mode distinction, then details the crucial differences between absolute and relative, and ends with a pointer to get_page. There is no filler; the length is justified by the complexity of the behavior.
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?
For a tool with two modes and interlinked parameters, the description covers the essential behavioral aspects: defaults, scaling/translation semantics, and the origin-shift effect. It also refers to get_page for geometry, covering the likely missing context. Since there is no output schema, and the operation is well-scoped, nothing critical is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds significant semantic nuance: it explains how defaults interact in absolute mode (scale defaults to 1, not current), and how relative scaling behaves (multiplies current size, around origin causing shift). This is beyond the schema's simple parameter descriptions and directly influences correct calls.
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 explicitly states the action ('Moves and/or scales a page element') and the underlying API (batchUpdate updatePageElementTransform). It clarifies the two operating modes (absolute vs relative) and the semantics of each, which distinguishes it from other tools that create or delete elements. The agent can immediately understand what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides concrete guidance: for a simple move, prefer relative translate only, and it explains the implications of absolute vs relative modes, including the pitfall that absolute moves reset scale. It also points to get_page for geometry, helping the agent reason about inputs. This is explicit when-to-use and how-to-use guidance, exceeding mere context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-google-slides MCP server](https://glama.ai/mcp/servers/A1-x-Tech/mcp-google-slides/badges/card.svg)](https://glama.ai/mcp/servers/A1-x-Tech/mcp-google-slides)

Score Badge

Copy to your README.md:

[![mcp-google-slides MCP server](https://glama.ai/mcp/servers/A1-x-Tech/mcp-google-slides/badges/score.svg)](https://glama.ai/mcp/servers/A1-x-Tech/mcp-google-slides)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/A1-x-Tech/mcp-google-slides'

If you have feedback or need assistance with the MCP directory API, please join our Discord server