getdeck

Render slide

render_slide

Read-onlyIdempotent

Fill one layout with your text and get back a finished, self-contained HTML document (theme, base and contract CSS inlined) that renders correctly when opened. Use it instead of get_layout when you already know the text: you do not assemble CSS or edit the markup yourself. Input: layout_id, optional theme_id (use the same one for every slide of a deck), slots, lang. Returns { layout_id, theme_id, html, warnings[], ok }. warnings[] lists missing required slots, text over max_chars, unknown slot ids and sample copy left behind, each with a fix; read them and call again after correcting, do not hand the user a slide that has errors. To validate without rendering use check_slots.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "layout_id": "<layout_id>",
      "slots": "<slots>"
    },
    "name": "render_slide"
  }
}

Input Schema

Name	Required	Description	Default
`lang`	No	Document language. Pass the language the slide text is written in.	ko
`slots`	Yes	Slot id to text, e.g. {"title": "Revenue grew 40%"}. Ids and limits come from get_layout / list_layouts slots[]. Plain text only: it is HTML-escaped, and a newline becomes a line break. Pass "" to leave an optional slot blank; a slot you omit keeps the layout's sample copy.
`theme_id`	No	Theme id or custom:<uuid>. Omit to use the layout's default theme, but pick one theme for the whole deck.
`layout_id`	Yes	Layout id from list_layouts or suggest_deck.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026
- addedInput schema / properties / layout_id / description
```
Added value: +"Layout id from list_layouts or suggest_deck."
```
AddedNov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds real behavioral substance beyond them: outputs are self-contained with theme/base/contract CSS inlined and render correctly standalone, and the return shape { layout_id, theme_id, html, warnings[], ok } is spelled out. The warnings taxonomy (missing required slots, over max_chars, unknown slot ids, leftover sample copy) plus the instruction to fix and re-call is exactly the kind of failure-mode disclosure an agent needs.

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 outcome, then usage contrast, then inputs, then return shape, then the warnings loop, then the validation alternative — a logical order with no filler. It is dense and runs long for a single paragraph, which slightly hurts scannability.

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 the full call cycle for a rendering tool with a nested slots object: where ids come from (get_layout/list_layouts), what happens to omitted vs empty slots, the exact return payload, and the remediation path. Nothing an agent needs in order to call it and act on the result is missing.

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 coverage is 100%, so baseline is 3, but the description adds cross-call meaning the schema lacks: theme_id should be identical across every slide in a deck, and slots is described as the agent's text rather than markup it must assemble. It does not restate schema detail such as the enum values for lang.

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?

"Fill one layout with your text and get back a finished, self-contained HTML document" states a specific verb, resource, and deliverable. It also names the sibling it replaces (get_layout) and the sibling for a different job (check_slots), so an agent can route correctly without opening any schema.

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 conditional routing: use this instead of get_layout "when you already know the text," and "To validate without rendering use check_slots." It also gives a correction loop (read warnings, fix, call again, don't hand the user a broken slide) and a deck-level rule to reuse one theme_id.

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

All getdeck tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?