Kadal Deck

Change a deck's settings

update_deck

Idempotent

Change a deck's title, visibility, passcodes or showcase listing — only the fields you pass change — and return the deck as saved. Use it to control who can open an already published deck; it never changes slide content (start_quick_edit, or the CLI via publish_deck) or the version served (rollback_deck). Needs decks:write (60 changes a minute); applies to new visitors at once and is undone by calling it again, though passcodes are stored only as hashes and can't be read back. Refused, with the reason, when the plan doesn't include private decks, passcode visibility has no viewing passcode, or the showcase is asked for on a non-public deck.

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": {
      "deck": "<deck>"
    },
    "name": "update_deck"
  }
}

Input Schema

Name	Required	Description
`deck`	Yes	The deck's id (starts with `d`) or its slug, as list_decks returns them; case-insensitive. A deck outside this workspace fails with “No deck …” — call list_decks.
`title`	No	A new title, up to 140 characters.
`showcase`	No	List the deck in the public showcase (the dashboard's Explore tab), where anyone signed in can find it. Public decks only; off by default, and not turned back on when a deck becomes public again. Ask the person before turning it on.
`visibility`	No	`public` (listed on the workspace's page), `unlisted` (anyone with the link) or `passcode` (viewers type the viewing passcode). Unlisted and passcode need the Starter plan or above. Leaving public also takes the deck out of the showcase.
`showcase_tags`	No	Up to 5 tags of 2–24 letters, digits and hyphens, e.g. ['lecture', 'data-vis']; replaces the current tags. Saved lower-case kebab with synonyms merged (dataviz → data-vis); words every deck has (slides, presentation) are refused.
`view_passcode`	No	What viewers type when visibility is `passcode`, 4–128 characters. Required when switching to `passcode` unless one is already set; replaces any earlier one.
`presenter_passcode`	No	Guards the presenter view, 4–128 characters; null removes it, omitted leaves it as is.

Output Schema

Name	Required	Description
`id`	Yes	The deck's id (also its live room's id).
`slug`	Yes
`urls`	Yes
`title`	Yes
`version`	Yes	The version being served.
`showcase`	Yes	The deck's place in the public showcase.
`createdAt`	Yes
`published`	Yes	Whether a version has been published and is being served.
`updatedAt`	Yes
`visibility`	Yes
`hasViewPasscode`	Yes
`hasPresenterPasscode`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

changedInput schema / properties / showcase_tags / description

Previous value: -"Up to 5 tags of at most 24 characters, e.g. ['lecture', 'data']; replaces the current tags."New value: +"Up to 5 tags of 2–24 letters, digits and hyphens, e.g. ['lecture', 'data-vis']; replaces the current tags. Saved lower-case kebab with synonyms merged (dataviz → data-vis); words every deck has (slides, presentation) are refused."

Changed7 schema fields changedOct 25, 2026

changedInput schema / properties / deck / description

Previous value: -"The deck's id (d…) or its slug, as list_decks shows them."New value: +"The deck's id (starts with `d`) or its slug, as list_decks returns them; case-insensitive. A deck outside this workspace fails with “No deck …” — call list_decks."

changedInput schema / properties / presenter_passcode / description

Previous value: -"The presenter view's passcode; null removes it."New value: +"Guards the presenter view, 4–128 characters; null removes it, omitted leaves it as is."

changedInput schema / properties / showcase / description

Previous value: -"List the deck in the public showcase (the dashboard's Explore tab), where anyone signed in can find it. Public decks only; off by default. Ask the person before turning it on."New value: +"List the deck in the public showcase (the dashboard's Explore tab), where anyone signed in can find it. Public decks only; off by default, and not turned back on when a deck becomes public again. Ask the person before turning it on."

changedInput schema / properties / showcase_tags / description

Previous value: -"Up to 5 short tags for the showcase, e.g. ['lecture', 'data']."New value: +"Up to 5 tags of at most 24 characters, e.g. ['lecture', 'data']; replaces the current tags."

changedInput schema / properties / title / description

Previous value: -"A new title."New value: +"A new title, up to 140 characters."

changedInput schema / properties / view_passcode / description

Previous value: -"The passcode viewers type when visibility is `passcode`."New value: +"What viewers type when visibility is `passcode`, 4–128 characters. Required when switching to `passcode` unless one is already set; replaces any earlier one."

addedInput schema / properties / visibility / description

Added value: +"`public` (listed on the workspace's page), `unlisted` (anyone with the link) or `passcode` (viewers type the viewing passcode). Unlisted and passcode need the Starter plan or above. Leaving public also takes the deck out of the showcase."

First observedOct 25, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well past the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false): it discloses the required scope `decks:write`, a 60/minute rate limit, that changes apply to new visitors immediately, that the call is reversible by re-invoking it, and the important caveat that passcodes are stored only as hashes and cannot be read back. These are non-obvious traits an annotation could never convey.

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 purpose and partial-update semantics in the first clause, and nearly every sentence carries distinct facts (scope, rate limit, hash caveat, refusal reasons). It is, however, a single dense paragraph with several em-dash clauses stacked, which costs some 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?

For a 7-parameter mutation with an output schema, annotations, and full schema coverage, the description supplies the remaining pieces: authorization, rate limit, mutability/reversibility, immediate propagation, and preconditions. Nothing an agent needs to call it correctly or predict failure 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 per-parameter meaning is already documented in detail; the description adds the cross-cutting partial-update rule ('only the fields you pass change') and names the passcode/sharing fields in prose. It stops short of adding format or enum guidance beyond the schema, which is reasonable given full coverage.

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 (change settings) and enumerates exactly which fields: title, visibility, passcodes, showcase listing. It also pins down the partial-update contract ('only the fields you pass change') and the return value, and explicitly excludes sibling operations (start_quick_edit, publish_deck, rollback_deck), so an agent can distinguish it 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?

Gives the selecting condition ('control who can open an already published deck') plus explicit negative routing to the three siblings that handle content edits and version changes. Refusal conditions (plan lacks private decks, passcode visibility without a passcode, showcase on a non-public deck) tell the agent when the call will fail before it tries.

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

All Kadal Deck tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.