Skip to main content
Glama
offscriptpontus

MakeSlates MCP Server

add_slide_from_template

Insert a new presentation slide using a pre-designed template; choose a template and append it or place it at a specific position.

Instructions

THE ONLY WAY TO ADD SLIDES - Uses pre-designed templates.

ALWAYS use this tool. NEVER use add_slide. Templates: title, section, image-full, two-column, quote, big-number, chart-bar, etc.

  1. Call list_templates first

  2. Pick the best template

  3. Use this tool to add the slide

  4. Use update_slide only to change text content

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
positionNoPosition to insert (0-indexed). Omit to append.
templateYesTemplate ID from list_templates (e.g. "title", "image-full", "two-column")
presentationIdYesThe presentation ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it does disclose a real behavioral constraint: templates must be discovered via list_templates first and this tool is the sole sanctioned path for adding slides. It does not cover failure modes, permission needs, or what the call returns, so it falls short of a 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-loaded with the primary directive and the sibling exclusion, then a compact numbered workflow. The ALL-CAPS emphasis is slightly noisy but each line carries distinct information.

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?

Three simple parameters, all schema-documented, no nested objects, and no output schema to explain, so the remaining need is behavioral routing — which the description supplies well. Minor gaps are the absence of any error/prerequisite detail for a mutation tool with no annotations.

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 baseline is 3, but the description goes further by enumerating template IDs (title, section, image-full, two-column, quote, big-number, chart-bar) beyond the schema's shorter example list, clarifying what the 'template' parameter accepts. It says nothing extra about 'position', though the schema already documents append-vs-insert.

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 (add slides) and immediately constrains it to pre-designed templates, which cleanly differentiates it from the sibling add_slide and from update_slide. An agent can pick this over siblings without opening the 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 says ALWAYS use this and NEVER use add_slide, then gives a 4-step ordering (list_templates → pick → add → update_slide for text). This is exactly the when/when-not/alternatives information the dimension asks for.

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