Skip to main content
Glama
gwmage

Rootr MCP Server

Create a Rootr presentation (slide deck)

rootr_create_presentation

Create a presentation slide deck in a Rootr workspace with custom themes, assertion-style slides, images, and diagrams. Text content from titles and blocks is indexed into the knowledge graph.

Instructions

Create a new PRESENTATION node (a slide deck) in a Rootr (루터) workspace, optionally seeded with an initial theme and 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
iconNoEmoji icon for the deck node
nameNoDeck name/title
themeNoDeck theme; missing keys fall back to sane defaults
configNoFree-form deck config/settings object
slidesNoInitial slides, in order
parentIdNoParent folder/node id to create the deck under
workspaceNoWorkspace id; defaults to ROOTR_WORKSPACE/config if omitted
Behavior5/5

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

Annotations (readOnlyHint=false) indicate mutation, and the description fully discloses the creation behavior. It reveals important behavioral details: diagrams/images are not indexed, images require prior upload, page numbers are auto-generated for certain slide kinds, and the canvas is 1280x720. These beyond-annotation details give the agent a clear understanding of side effects and limitations.

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: it begins with the core purpose, then flows into authoring guidelines, image specifics, slide roles, and page number behavior. Every sentence adds value, though some details (e.g., the exact mermaid diagram type) could be omitted. It is front-loaded with the essential purpose.

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 (7 parameters, nested objects for slides, blocks, images), the description covers all critical aspects: canvas size, knowledge graph indexing, image sourcing workflow, slide kind semantics, layout hints, and auto-numbering. It also references sibling tools for auxiliary tasks. No output schema is present, but the description sufficiently explains what the tool produces.

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 significant semantic value beyond the input schema. It explains the authoring guide for slides (assertion-style titles, blocks structure), image handling (alt text importance, upload process, placement), diagram constraints, and the role of 'kind'. This helps the agent construct complex nested objects correctly.

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: 'Create a new PRESENTATION node (a slide deck)'. It specifies the resource (presentation), action (create), and context (Rootr workspace). This distinctively sets it apart from siblings like rootr_read_presentation or rootr_update_presentation.

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?

The description provides extensive usage guidance on how to author slides, including assertion-style titles, blocks, diagrams, images, and slide roles. It references complementary tools (rootr_generate_image, rootr_remove_image_background). However, it does not explicitly contrast with sibling tools or state when to use this tool versus alternatives; the guidance is more about effective usage than selection criteria.

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