Skip to main content
Glama

Metis — Create Poster

create_poster

Generate a conference poster (.pptx) from structured sections, automatically filling the researcher’s chosen template and flagging text likely to overflow.

Instructions

Create a conference poster (.pptx) filled into the researcher's own template.

The poster template is stored in Metis (see list_templates) and used by
default — never ask the researcher for the file or where it is.

The template (.potx or .pptx) is looked up in system/config/local/templates/,
knowledge/templates/, or $METIS_TEMPLATES_DIR — or pass a path. Each layout's
section boxes are detected from its geometry, so any template with a title,
small section headers and large content boxes works.

Args:
    title: Poster title.
    sections: The poster body as plain text. Each section starts with a line
        beginning "# " (its heading); following lines are its text. Lines
        beginning "- " become points, "## " a block subtitle inside the box,
        anything else plain prose. Sections fill the boxes down the first
        column, then the next. Example:

            # Background
            - Why the question matters
            # Methods
            - Design, setting, data
            # Results
            - The main finding, with its number
    authors: Authors line, shown under the title.
    band: Optional text for the band below the title — affiliations, or a
        one-sentence key message.
    template: Template file name (or part of it) or a path. Empty = the first
        template found; the result says which one was used.
    layout: "auto" (smallest layout with enough boxes), or part of a layout
        name such as "one column" / "two column".
    filename: Optional output filename; derived from the title when omitted.

Returns:
    The path written, the template and layout used, and any section whose text
    is likely to overflow its box.

Input Schema

NameRequiredDescriptionDefault
bandNo
titleYes
layoutNoauto
authorsNo
filenameNo
sectionsYes
templateNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A4.5/5.0
Behavior4/5

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

No annotations, so the description carries the full burden, and it does substantial work: it discloses the template search order (config dirs, knowledge/templates, $METIS_TEMPLATES_DIR), geometry-based layout detection, column-fill order, and that the result reports possible overflow. It omits overwrite behavior when the output filename already exists, which matters for a file-writing tool.

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 core purpose, then structured Args/Returns blocks that keep it navigable despite its length. The example under `sections` is justified by the custom syntax, though the template-location sentence partially repeats the opening 'never ask' instruction.

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?

A 7-param file-generating tool with no annotations and no schema descriptions, yet the description covers source resolution, section formatting, layout selection, output naming, and return contents (path, template used, overflow warnings — also backed by the output schema). Nothing an agent needs to invoke it 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 description coverage is 0% across 7 params, and the description documents every one, including a worked mini-language grammar for `sections` (# headings, - bullets, ## sub-blocks, column fill order), 'auto' layout semantics, and template substring-or-path matching. This fully compensates for the empty 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?

Opens with a specific verb and artifact: 'Create a conference poster (.pptx) filled into the researcher's own template.' The template-insertion framing distinguishes it from create_presentation (blank deck) and fill_document_template (non-poster docs) 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?

Explicitly routes the agent: templates come from Metis via list_templates, and 'never ask the researcher for the file or where it is' is a clear when-not instruction. However, it never contrasts with create_presentation or fill_document_template, which are the most likely confusable siblings.

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