Skip to main content
Glama
gwmage

Rootr MCP Server

Append slides to a Rootr presentation (preferred way to add slides)

rootr_append_presentation_slides

Append new slides to the end of a Rootr presentation without altering existing content. Each slide requires an assertion-style title and text blocks for knowledge graph indexing.

Instructions

Append one or more slides to the END of a Rootr (루터) PRESENTATION, without touching existing slides. PREFER this over rootr_update_presentation when you are only adding new slides. Authoring guide: give each slide ONE assertion-style title (a claim, e.g. "Latency dropped 40% after the cache fix" — not a topic label like "Latency"), plus blocks[] (bullet-like {id, heading?, body?, icon?} items) and, where useful, a diagram ({type:"mermaid", code}) or images. Canvas is 16:9 (1280x720). Meaning must live in TEXT — title/blocks[].heading/blocks[].body/notes are what auto-connects into the knowledge graph; diagrams/code/html and the image pixels themselves are visual-only and are NOT indexed, so never put facts ONLY in a diagram or picture. Images: image is the single primary/background image (cover, section, full-bleed); images[] holds additional inserted images placed on the slide. Each image is {id?, src?, alt?, placement?, prompt?, x?, y?, w?, h?}. Set src to an uploaded file URL (upload via POST /v1/attachments/upload, then use /api/v1/attachments/{id}/raw), an https URL, or a data: URI — you cannot upload the file bytes through these MCP tools, only reference the resulting URL. To get a REAL image, call rootr_generate_image with an English prompt (say "no text"), then put the returned url into the slide image's src; rootr_remove_image_background cuts out an image's background. placement is a layout hint ("full"|"right"|"top"|...); x/y/w/h give freeform PPT-style placement in 1280x720 canvas coords. ALWAYS add an alt caption to every image — alt text is part of the graph text spine, so a captioned image connects into the knowledge graph while an uncaptioned one does not. Use kind to mark each slide's role: "cover" (deck title slide), "section" (chapter divider), "content" (body slide, the default), "closing" (last slide / call to action). Page numbers: "content" and "section" slides automatically show a page number that follows the slide order (it re-numbers itself when slides are reordered), so you do NOT set it yourself. "cover"/"closing" have none by design.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slidesYesSlides to append, in order
presentationIdYesPRESENTATION node id
Behavior5/5

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

Discloses non-destructive behavior by specifying existing slides are untouched. Explains page numbering auto-removes 'cover'/'closing' slides, and that diagrams/images are not indexed. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).

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?

First sentence clearly states the primary action. While the description is long, every section earns its place by providing crucial authoring guidance. Could be slightly condensed, but very well-structured.

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?

Covers all aspects: how to get images, upload process, background removal, knowledge graph indexing, layout hints, page numbering. No output schema needed since appending slides is straightforward. Fully adequate for an agent to use correctly.

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 100%, but the description adds substantial meaning: assertion-title format, text spine concept, image placement details, alt text necessity, kind roles. Enriches understanding beyond schema property 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?

The description clearly states the tool appends slides to the end of a presentation without touching existing slides. It distinguishes from rootr_update_presentation by explicitly recommending this tool when only adding slides.

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 advises to prefer this over rootr_update_presentation when adding slides. Provides detailed authoring guidelines for slide content, including assertion-style titles, text spine importance, and image handling. References sibling tools like rootr_generate_image and rootr_remove_image_background correctly.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gwmage/rootr-cli'

If you have feedback or need assistance with the MCP directory API, please join our Discord server