Skip to main content
Glama
offscriptpontus

MakeSlates MCP Server

create_presentation_with_slides

Create a full slide deck in one call by passing a title and slides, each using a template ID and content fields mapped to element roles.

Instructions

Create a presentation with slides in one call.

Each slide needs a template ID and content fields. Use list_templates to see all templates and their contentFields.

Content fields map to element roles - pass them directly: { template: "big-number", number: "42%", label: "Growth" }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesTitle of the presentation
slidesYesArray of slides with template and content
darkModeNoSet to true for dark theme
workspaceIdNoWorkspace ID to create in (omit for personal)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/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 the meaningful behavior that presentation and all slides are produced atomically in one call, plus how content fields map to element roles. It says nothing about permissions, validation failures, or limits on slide count, which matter for a creation 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?

Three short, front-loaded lines with zero filler; the atomicity claim leads, then the prerequisite, then a worked example. Every sentence earns its place.

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

Completeness3/5

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

Covers the core contract (template required, content fields are role-keyed) and points to list_templates, which is the main gap an agent would hit. But with no annotations and no output schema it leaves workspace scoping, dark-mode behavior, and the shape of the result unexplained.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents title, template, darkMode and workspaceId, establishing a baseline of 3. The description adds real value on the loosely-typed content fields (mapping them to element roles via a concrete example) but omits darkMode and workspaceId entirely.

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

Purpose4/5

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

States a concrete verb+resource ('Create a presentation with slides') and adds the key scope detail 'in one call', which implies a batch alternative to create_presentation plus add_slide_from_template. It never names those siblings explicitly, so the differentiation is left partly to inference.

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

Usage Guidelines3/5

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

Provides one explicit prerequisite: 'Use list_templates to see all templates and their contentFields.' That is genuine routing guidance. However it gives no when-to-use-vs-when-not guidance against create_presentation or add_slide_from_template, so the choice among creation paths is implied rather than stated.

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