Skip to main content
Glama
gwmage

Rootr MCP Server

Update a Rootr presentation (theme/slides/config)

rootr_update_presentation

Update a presentation's theme, config, or replace all slides using a merge patch. Existing content stays unless explicitly overridden.

Instructions

Merge-patch a Rootr (루터) PRESENTATION: update theme and/or config, or REPLACE THE WHOLE slides array (if you pass slides, it replaces every existing slide — call rootr_read_presentation first and resend slides you want to keep, or use rootr_append_presentation_slides / rootr_update_presentation_slide instead for incremental changes). 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
iconNoEmoji icon for the deck node
themeNoDeck theme; missing keys fall back to sane defaults
configNoFree-form deck config/settings object
slidesNoCOMPLETE slides array to set — omitted existing slides will be dropped
presentationIdYesPRESENTATION node id
Behavior5/5

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

The description discloses that passing slides replaces all existing slides (destructive behavior), and explains image indexing, page numbering, and more. No contradiction with annotations.

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?

The description is lengthy but well-structured and front-loaded with key behavior. Every sentence adds value, though a minor trim could improve conciseness.

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?

Given the tool's complexity (5 params, nested objects, no output schema), the description is thorough: covers update semantics, slide authoring, images, usage guidelines, and sibling relationships. An agent can use it effectively.

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?

Despite 100% schema coverage, the description adds substantial meaning: merge-patch behavior, slide replacement, authoring guide for titles, blocks, images, and knowledge graph integration. This goes well beyond the schema.

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's purpose: update a presentation by merging theme/config or replacing the slides array. It uses specific verbs and resources, and distinguishes from sibling tools for incremental changes.

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?

Explicit guidance is provided: read presentation first, resend slides to keep, or use alternative tools for incremental changes. Authoring guidelines for slides are also given.

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