Skip to main content
Glama

ShareWatch

by ai.sharewatch
OverviewDiscussionsAdmin

Build Presentation

build_presentation

Create a Google Slides deck from a structured outline. Unlike create_presentation, which takes raw slides, this one applies Google's own layouts, so it suits decks meant to look designed. Pick a layout per slide and fill only the slots that layout provides; Google positions everything via placeholders (no manual geometry). Layouts are Google's own PredefinedLayout names, so they match the Slides API you already know. Layout → slots: TITLE = title + subtitle (opening slide); SECTION_HEADER = title only (a divider — no subtitle); TITLE_AND_BODY = title + bullets OR body; TITLE_AND_TWO_COLUMNS = title + body/bullets (LEFT) + body_right/bullets_right (RIGHT) — fill both sides or the empty one shows as a blank box when edited; MAIN_POINT / BIG_NUMBER / TITLE_ONLY = title only; BLANK = nothing. Set bullets for lists (it wins over body when both are given); keep each slide to one idea. Workflow: build, then call describe_slides to catch dropped content / overflow / overlap, then preview_slides for a final visual check.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesPresentation title
slidesYesSlides in order. Each picks a layout and fills its slots (title/subtitle/body/bullets/notes); Google positions everything via placeholders.
accountNoWhich connected Google account to create in, by its address, when the user has more than one — see get_status connections. Omit for the primary account.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
urlYes
accountNothe Google account the file was created in; present only when more than one is connected

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / account
      Added value: +{
+  "description": "Which connected Google account to create in, by its address, when the user has more than one — see get_status connections. Omit for the primary account.",
+  "type": "string"
+}
    • addedOutput schema / properties / account
      Added value: +{
+  "description": "the Google account the file was created in; present only when more than one is connected",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • removedOutput schema / additionalProperties
      Removed value: -false
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the write/additive nature is already known. The description adds substantial behavioral context beyond that: positioning happens via placeholders with no manual geometry, an unfilled two-column side renders as a blank box, and bullets wins over body/body_right when both are supplied. It stops short of describing auth/permission needs, so 4 rather than 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Front-loads purpose and sibling differentiation before the dense layout catalogue and workflow, and nearly every clause carries decision-relevant information. The layout→slots run-on (particularly the TITLE_AND_TWO_COLUMNS entry) is long and would read better as structured lines, which keeps it from a 5.

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 nested-content creation tool with 100% schema coverage and an output schema (so return values need not be explained), the description covers the remaining gaps: layout semantics, slot requirements, fill precedence, and the recommended verification workflow. Nothing an agent needs to call 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?

Schema coverage is 100%, setting the baseline at 3, but the description adds meaning the schema does not: a layout→slot mapping (TITLE = title + subtitle; SECTION_HEADER = title only; TITLE_AND_TWO_COLUMNS = left/right slots; BLANK = nothing) and precedence rules for bullets. This clarifies how the fields interact per layout rather than merely restating them.

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+resource (create a Google Slides deck from a structured outline) and immediately distinguishes itself from the sibling create_presentation by noting it applies Google's own layouts rather than taking raw slides. The layout-based approach is spelled out concretely, so the agent can tell the two apart without opening either schema.

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?

Explicitly routes the agent between alternatives ('Unlike create_presentation, which takes raw slides, this one applies Google's own layouts, so it suits decks meant to look designed') and provides a full workflow: build, then describe_slides to catch dropped content/overflow/overlap, then preview_slides for a visual check. When-to-use and follow-up tools are both covered.

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

All ShareWatch toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources