Kadal Deck

Read the live room

get_live_room

Read-only

Read a deck's live room as it is right now: whether a talk is live, the presenter's slide, the audience and where they are, raised hands and pace votes, questions (unanswered first, then most-voted), and poll, word-cloud, quiz and reaction tallies. Use it during or just after a talk — to summarise questions or report a poll; use get_deck_stats for history across past sessions. Read-only: it observes and never changes the room, but successive calls differ as the room moves. live is false when neither the presenter nor any viewer is connected.

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": "get_live_room"
  }
}

Input Schema

Name	Required	Description	Default
`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.

Output Schema

Name	Required	Description	Default
`live`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field 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."

First observedOct 25, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover readOnlyHint=true and destructiveHint=false, but the description adds real value: it explains why idempotentHint=false matters ('successive calls differ as the room moves') and defines the edge case that `live` is false when neither presenter nor viewers are connected. It stops short of describing snapshot timing or staleness/polling guidance, which would be the final piece for a tool that returns a moving target.

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?

Purpose is front-loaded, followed by the content inventory, then usage routing and behavior. The long enumerations of room contents are dense but each item maps to something the agent can actually surface, so little is wasted; the sentence is slightly over-packed rather than padded.

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 single-parameter read tool with an output schema, annotations and a fully documented param, the description covers the remaining gaps: when to call it, what it does not replace, and the non-idempotent snapshot nature. An agent has everything needed to select and invoke it correctly.

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 coverage is 100% and the `deck` parameter already documents id-or-slug format, case-insensitivity, and the recovery path on a bad id, so the description adds nothing parameter-specific. Baseline 3 applies when the schema carries the full burden.

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 ('Read a deck's live room as it is right now') and enumerates the contents returned: live status, presenter slide, audience presence, raised hands, pace votes, questions and poll/word-cloud/quiz/reaction tallies. It explicitly contrasts with get_deck_stats, so an agent can separate it from the nearest sibling 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 Guidelines5/5

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

Gives an explicit when ('during or just after a talk — to summarise questions or report a poll') and names the alternative with the condition that selects it ('use get_deck_stats for history across past sessions'). Both the use case and the exclusion are stated, not inferred.

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.