Skip to main content
Glama
Sign In

Kadal Deck

by cc.kadal
OverviewDiscussionsAdmin

Look up a Kadal Deck feature

deck_reference
Read-onlyIdempotent

Look up what a deck can use — components with props, defaults and examples, layouts, backgrounds, themes, frontmatter keys, CLI commands — from the engine's own catalog (exact for @kadal/deck 0.12.0), plus the docs' guides. Use it to check a component or option before writing it; use authoring_guide instead for the overall how-to. Read-only. Pass one mode: nothing for an index of sections and guides, section (plus name for one entry), topic for a guide in full, or search for the best matches across both; if several are given, section wins, then topic. An unknown section, entry or topic is an error that lists the valid ones.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "deck_reference"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoOne entry in `section`, by name or alias, e.g. Poll, two-cols, aurora. Needs `section`.
topicNoA guide's topic id from the no-argument index, e.g. writing-slides, live-room, islands/vue.
formatNoFor `section` or `search`: markdown (default) reads best; json is the raw data. Guides are always markdown.
searchNoWords that must all appear, e.g. "word cloud"; returns up to 12 catalog entries and 5 guide sections.
sectionNoA catalog section: components, layouts, backgrounds, themes, transitions, transitionSpeeds, clickEffects, clickAt, codeMeta, deckFrontmatter, slideFrontmatter, keys, routes, queryParams, live, cli, exitCodes. Aliases such as slide, deck, clicks and code work.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / format / description
      Previous value: -"For a section or search: markdown (default) reads best; json is the raw data."New value: +"For `section` or `search`: markdown (default) reads best; json is the raw data. Guides are always markdown."
    • changedInput schema / properties / name / description
      Previous value: -"One entry in the section, e.g. Poll, two-cols, aurora."New value: +"One entry in `section`, by name or alias, e.g. Poll, two-cols, aurora. Needs `section`."
    • changedInput schema / properties / search / description
      Previous value: -"Words to find, e.g. \"word cloud\"."New value: +"Words that must all appear, e.g. \"word cloud\"; returns up to 12 catalog entries and 5 guide sections."
    • changedInput schema / properties / section / description
      Previous value: -"A catalog section, e.g. components, layouts, backgrounds, slideFrontmatter."New value: +"A catalog section: components, layouts, backgrounds, themes, transitions, transitionSpeeds, clickEffects, clickAt, codeMeta, deckFrontmatter, slideFrontmatter, keys, routes, queryParams, live, cli, exitCodes. Aliases such as slide, deck, clicks and code work."
    • changedInput schema / properties / topic / description
      Previous value: -"A guide's topic id, e.g. live-room."New value: +"A guide's topic id from the no-argument index, e.g. writing-slides, live-room, islands/vue."
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered; the description adds real context beyond that — version-accuracy scoping (@kadal/deck 0.12.0) and failure behavior (an unknown section, entry or topic is an error that lists the valid ones). It does not describe result size limits beyond search's counts or how the index itself is shaped, which keeps it short of a 5.

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?

It is dense but well ordered: purpose and scope first, then the alternative tool, then read-only, then the mode rules and error behavior. It is a single long paragraph with semicolon-chained clauses, which slightly hurts scannability, but no sentence is filler.

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 zero-required-param lookup tool with no output schema, the description covers what each invocation mode returns (an index, a single entry with props/defaults/examples, a full guide, or ranked matches) and what happens on miss. An agent can pick a mode and predict the response shape without further information.

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 description coverage is 100%, so the baseline would be 3, but the description adds meaning the schema does not: the no-argument invocation returns an index of sections and guides, `section` + `name` composes, and precedence when several mode parameters are supplied. That precedence rule is genuinely non-obvious behavior not encoded in any parameter description.

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 description opens with a specific verb and resource — 'Look up what a deck can use' — and enumerates the concrete content classes (components with props, defaults and examples, layouts, backgrounds, themes, frontmatter keys, CLI commands) plus the source ('the engine's own catalog'). It explicitly names the sibling it is not, authoring_guide, so an agent can route between 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 Guidelines5/5

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

It gives a positive trigger ('check a component or option before writing it'), an explicit alternative ('use authoring_guide instead for the overall how-to'), and a full mode-selection rule with precedence: nothing for an index, `section`/`name`, `topic`, or `search`, with `section` winning over `topic` if both are passed. That is the when/when-not/alternatives bar and it names the alternatives directly.

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

All Kadal Deck toolsInspect
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.

Resources