Skip to main content
Glama

Render a slide to an image

render_slide
Read-only

Converts a GlideDeck slide or whole canvas to PNG, returning the image to check layout, overflow, and contrast and optionally save it.

Instructions

Renders a slide (1-based step; 0 = the whole canvas) to a PNG and returns it, so you can check layout, overflow and contrast. Optionally also saves it.

Input Schema

NameRequiredDescriptionDefault
pathYesThe GlideDeck project file (.glide.json). Absolute, or relative to the server's folder; `.glide.json` is added when there is no extension.
stepNo
widthNo
save_toNoOptional .png path to also write.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior3/5

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

The description usefully discloses that an image is returned (enabling visual verification) and that it can optionally persist a file via save_to. However, that file-writing side effect sits in tension with readOnlyHint=true, so an agent relying on the annotation would mispredict the tool's effect on the environment.

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

Conciseness5/5

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

Two compact sentences: the core action and step semantics come first, followed by the optional-save caveat. No filler, no restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly states the return value (a PNG image) and the verification purpose, which is what an agent needs to interpret results. The unexplained `width` parameter (default 1280) is the only meaningful gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50%, but the description compensates by explaining `step` (1-based, 0 = whole canvas) and `save_to` ('optionally also saves it'). Only `width` remains undocumented in both places, so the description adds real meaning over 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?

States a specific verb and resource ('renders a slide ... to a PNG and returns it') and clariifes the special step semantics (1-based; 0 = whole canvas). This distinguishes it from siblings like export_pptx/export_pdf, which produce deck-level deliverables rather than a single-slide inspection image.

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?

Gives a clear intended use ('so you can check layout, overflow and contrast'), which tells the agent when this tool is appropriate. It stops short of naming alternatives such as export_pdf or open_in_editor, so selection among visually-oriented siblings is still left to inference.

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