Skip to main content
Glama

Metis — Create Presentation

create_presentation

Turn a plain text outline into a PowerPoint (.pptx) deck, converting headings to slide titles, lines to bullets, and quoted lines to speaker notes.

Instructions

Create a PowerPoint (.pptx) file from a simple text outline.

The tool that closes the largest gap in Claude Desktop: Metis could read
presentations but never produce one, so any "make me a deck" request had no
way to land as a file.

Args:
    title: Deck title, used on the title slide and in the filename.
    slides: The deck as plain text. Each slide starts with a line beginning
        "# " (the slide title); every following line becomes a bullet.
        A line beginning "> " becomes speaker notes for that slide.
        Blank lines are ignored. Example:

            # Why passive surveillance underperforms
            Health-facility detection depends on care-seeking
            Median delay to diagnosis exceeds 12 months
            > Open with the Mitashi 2014 figure

            # What changes with RDTs at the periphery
            Sensitivity holds at lower prevalence
        A line beginning "## " starts a section-divider slide instead.
    subtitle: Optional subtitle for the title slide.
    filename: Optional filename; derived from the title when omitted.
    template: The researcher's slide template stored in Metis (name or part
        of it). Empty = their default deck template if one is stored (see
        list_templates) — never ask them for the file. "none" = plain deck.
    closing: Text for the template's closing slide under "Thank you!" —
        e.g. presenter name, e-mail, website. Empty = no closing slide.

Returns:
    The path written and a slide count.

Input Schema

NameRequiredDescriptionDefault
titleYes
slidesYes
closingNo
filenameNo
subtitleNo
templateNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden and largely meets it: it declares the tool writes a .pptx file, explains filename derivation from title, spells out template resolution (empty = stored default, "none" = plain deck) and that empty closing produces no closing slide. It omits what happens if the filename already exists, where on disk the file lands, and whether writing is reversible — real gaps for a filesystem-mutating tool, but the defaults disclosure is well above average.

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

Conciseness3/5

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

The purpose sentence is correctly front-loaded and the Args section is dense with load-bearing detail. However, the two-sentence aside about "the largest gap in Claude Desktop" and Metis being unable to produce decks is promotional narrative that does not help an agent decide or invoke, and it sits between the purpose and the actual spec.

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?

An output schema exists, so the brief "Returns" line is sufficient. All six parameters, including optional ones and their empty-string defaults, are covered, and the non-obvious free-text format is fully specified with an example — nothing an agent needs to call this correctly 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?

Schema coverage is 0%, so the description had to compensate fully and does: all six parameters are documented, and the slides mini-language (# title, ## section divider, > speaker notes, blank lines ignored) is specified precisely enough to author input correctly, with a worked example. The template semantics (name or partial name, empty vs "none") are the kind of detail no schema could carry.

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 artifact: "Create a PowerPoint (.pptx) file from a simple text outline." That artifact-level specificity distinguishes it from siblings like create_poster and create_document without naming them, and the second half of the sentence tells the agent what input it needs.

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?

There is one genuine usage directive buried in a parameter: template of empty means use the stored default and "never ask them for the file," plus a pointer to list_templates. But there is no explicit when-to-use guidance relative to create_poster/create_document, and the second paragraph explains why the tool exists rather than when to call it.

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

Deploy Server

Other Tools