Kadal Deck

Get a deck's sync state

get_deck_sync

Read-onlyIdempotent

Check whether a deck can be quick-edited in the web builder and whether other work is in flight: the live version and where it came from, any web draft editing it (draft.dirty = unpublished changes, plus its builder link), and quickEdit — ready, needs-republish (publish once with kadal-deck 0.5+), no-source (published with --no-source) or disabled (nothing published, or too big for the browser; reason says which). Use it before start_quick_edit, and before publishing over a deck from the CLI so someone's unpublished web edits aren't replaced; use list_versions for the full history. Read-only.

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_deck_sync"
  }
}

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
`quickEdit`	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.2/5.0

Behavior3/5

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

Annotations already cover readOnlyHint, idempotentHint and destructiveHint, and the trailing 'Read-only' merely repeats them. However, the description adds real behavioral context by decoding the quickEdit states (needs-republish, no-source, disabled) and explaining draft.dirty as unpublished changes. With an output schema present, return-shape detail is not required, so the added enum semantics justify a score above baseline but not top marks.

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 core purpose, then usage. It is dense with backticked state names and parenthetical glosses, which is efficient but makes the sentence heavy; nearly every clause still earns its place.

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 read-only single-parameter tool with an output schema and full annotation coverage, nothing an agent needs to call it correctly is missing: purpose, preconditions, state meanings, and sibling routing are all present.

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 single `deck` parameter is fully documented in the schema (id or slug, case-insensitive, failure mode). The description adds nothing about the parameter, so the baseline 3 is correct.

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 ('Check whether a deck can be quick-edited') and enumerates exactly what it returns: live version, provenance, web draft, and the four quickEdit states. An agent can tell it apart from get_deck and list_versions 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 Guidelines5/5

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

Gives explicit triggers ('Use it before start_quick_edit, and before publishing over a deck from the CLI') with the reason (avoid clobbering unpublished web edits), and names the alternative for history ('use list_versions'). Nothing is left to inference.

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.