Skip to main content
Glama

Get a demo

get_demo
Read-onlyIdempotent

One demo in full: its content document (guided: steps; clickable: hotspots and startScreenId; plus description), its screens (ids, names, sizes, captured page title and address, whether it has an HTML snapshot), share settings, published state, hosted URL and embed code, and revision (pass it to update_content). Look at a screen with get_screen.

Steps (guided demos), in order:

  • tip: { id, kind:"tip", screenId, title ≤200, body ≤2000, spot:{x,y,w,h} (percent of the screenshot), place:"auto"|"top"|"right"|"bottom"|"left", advance:"click"|"next"|"timer"|"narration" ("narration": continues when the step's narration ends), timerMs 1000–60000, hotspot:"pulse"|"outline"|"hidden", zoom, dim, camera?, cursor?, spotlight? } Tooltip camera and motion (optional; left out = the demo default in settings.motion): "camera": { mode?: "auto" (zoom to the spot) | "frame" (show camera.frame) | "off", frame?: {x,y,w,h} percent of the screenshot (fitted to the stage, 1–4× zoom), transition?: "glide"|"cut", speed?: "slow"|"normal"|"fast" }, "cursor": true|false (animated cursor that moves to the spot and clicks), "spotlight": "rounded"|"circle" (the cutout shape with dim). Without camera.mode, zoom: true means "auto".

  • intro / chapter / cta / outro cards: { id, kind, screenId (or null), title, body, cta ≤60 (button label), ctaUrl (https://, mailto: or tel:, or null), theme:"dark"|"light" }

  • form (lead form): { id, kind:"form", screenId, title, body, cta, fields: ["email", "name"?, "company"?, "phone"?] (email required), theme } Branching (any guided step but a form): "choices": 2–4 of { id, label ≤60, target: {type:"step",stepId} | {type:"end"} | {type:"url",url} | null } (a card shows them instead of its button; a tooltip shows them as buttons) — set_choices is the easy way. "next" on any step: {type:"step",stepId} or {type:"end"}: where the default path goes after it (absent: the following step); use it to skip ahead, rejoin or end a path. Personalization: titles, bodies, button labels, choice labels, hotspot labels and links can hold {{key}} or {{key|fallback}} (built-ins first_name, last_name, full_name, company, title, email; custom ones declared in content.variables as { key, label, default?, sample? }). Each viewer sees their own values (personalized links, URL parameters), everyone else the fallback or default. Keep the tokens when rewriting copy. Hotspots (clickable demos): { id, screenId, rect:{x,y,w,h}, label ≤120, hint ≤300, target: {type:"screen",screenId} | {type:"url",url} | null }, plus "auto": true on navigation links made by stitch_demo (shown quietly) and "link": a group id the same control shares on every screen. Plus startScreenId and description (≤300, shown under the title on the hosted page). Narration (voiceovers, Pro and Team): "voiceover" on any guided step: { script ≤1000 (what a voice says when the step appears: short, spoken, separate from the tooltip text), source:"ai"|"recorded"|"uploaded", clip: { key, durationMs, cues, hash, voiceId? } | null }. Clickable demos keep it per screen in "screenVoiceovers": { "": same }. "voice": { voiceId (list_voices), speed 0.7–1.2, stability 0–1 } is the demo's AI voice. Make clips with generate_voiceovers; never write a clip key yourself (it must be this demo's audio). Other fields present in the document (newer features) are kept as they are; the server validates the whole document.

Requires: demos:read.

Input Schema

NameRequiredDescriptionDefault
demoIdYesDemo id (from list_demos), e.g. "d_Ab12Cd34Ef56Gh78".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds genuinely non-obvious context beyond them: the 'demos:read' scope requirement, that `revision` is a concurrency token for update_content, that unknown newer fields are preserved as-is, and that the server validates the whole document. What's missing is any note on payload size or whether large demos are truncated.

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

Conciseness2/5

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

The summary is well front-loaded, but the body then expands into a multi-hundred-word prose re-specification of the entire content document (camera options, branching target types, personalization tokens, voiceover clip internals). Nearly all of that is field-level schema detail that belongs in the write tools' schemas, not in a read tool's description; the reader must wade through it to reach the one operational note (revision → update_content).

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?

There is no output schema, so the description legitimately must describe the return shape, and it does so thoroughly across guided steps, clickable hotspots, share/publish fields and the revision token. It is short only on what 'share settings' actually contain, but an agent has enough to call the tool and use the result.

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

Parameters3/5

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

There is a single parameter with 100% schema description coverage (including a pattern and an example), so the schema carries the semantics. The description adds nothing about `demoId` itself — no hint that it comes from list_demos or how to handle an unknown id — which matches the baseline for a fully-documented 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 opening sentence names a specific resource and enumerates its scope precisely: content document, screens, share settings, published state, hosted URL, embed code, and revision. It also explicitly names the sibling get_screen for the narrower screen-level case, so an agent can distinguish the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the 'pass it to update_content' note and 'Look at a screen with get_screen' route the agent to two related tools, but there is no explicit 'use this when you need X instead of list_demos' framing. The agent must infer that this is the inspect-before-mutate call.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.