Skip to main content
Glama

get_deck

Fetch a presentation deck by ID to retrieve its title, description, and ordered slides, each slide showing a diagram ID and title.

Instructions

Fetch one deck by id. Returns its title, description, and the ordered list of slides (each slide is a diagram id + title in presentation order).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesDeck UUID
spaceNoWhich workspace to act in: its id, its slug, or its exact name (case-insensitive). Omit to use this token's default workspace. Call list_spaces to see what this token can reach. A name that matches more than one workspace is refused — pass the id or slug instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.0.7
    • addedInput schema / properties / space
      Added value: +{
      +  "description": "Which workspace to act in: its id, its slug, or its exact name (case-insensitive). Omit to use this token's default workspace. Call list_spaces to see what this token can reach. A name that matches more than one workspace is refused — pass the id or slug instead.",
      +  "type": "string"
      +}
  2. Addedv0.0.4

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It usefully discloses the return shape (title, description, ordered slides as diagram id + title), but says nothing about permissions, error behavior for an unknown id, or whether the space parameter affects visibility. Some value added, but gaps remain for a tool with zero annotation coverage.

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?

Two tight sentences with the operation front-loaded and no filler. Slightly dense parenthetical about slide structure, but every clause conveys real information.

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?

For a simple read tool with a fully documented schema and no output schema, the description covers purpose and return contents well. The only missing piece is behavioral context around permissions or failure modes, which is minor here.

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?

Schema description coverage is 100%, so both parameters (id, space) are fully documented in the schema, including the space fallback and ambiguity-refusal rules. The description adds nothing beyond what the schema already states, which is the correct baseline when the schema does the heavy lifting.

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 (fetch) and resource (one deck by id), and the second sentence clarifies it retrieves a single deck rather than a collection, distinguishing it from list_decks. An agent can identify the operation without opening the 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 by 'one deck by id' versus the sibling list_decks, but there is no explicit when-to-use statement, no mention of prerequisites, and no routing guidance to alternatives. Adequate but leaves inference to the agent.

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