Skip to main content
Glama

scene_add_card_selector

Destructive

Adds a card selector window to a copied save so players can pick one or more cards, such as upgrades or rewards, when a graph opens it and returns the choice.

Instructions

Add a card selector (卡牌选择器) to a copy of a save: the platform's own window in which a player picks one or more cards out of a few, each with an icon, a title and a description (three upgrades to choose from after a wave, a reward, a class at the start); in a level for one player the game stands still while it is open. cards is the library of cards the window can show, {title, description, icon, label} each, or {unknown: true, label} for a card that hides what it is. A graph opens the window for a player with f.invokeDeckSelector, saying which cards of the library to show this time and what value each gives back, and the choice comes to a graph on the player template as whenDeckSelectorIsComplete; the answer of this tool gives both lines. seconds is the time to choose in (the graph may give another). canGiveUp: false takes the button 放弃选择 away (the player has to choose), canFold: false the button that folds the window away, pauseWhenAlone: false lets the game run on behind it, showTime: false hides the countdown; all four are on unless said. The selector stands in no layout: it shows only when a graph opens it, and not in the first seconds of a level (opened at level second 3 it did not show and the choice came back as the default twenty seconds later; at second 14 it showed: open it some seconds in, or on something the player did). The window has a title, a countdown, the cards in a row, 放弃选择 and 确认选择; a playtest picks a card with an input {clickText: its label} and then {clickText: "确认选择"}. Icons seen in the official sample: 91001 a sword (the one a card has when none is given), 91011 a polearm, 91016 a catalyst, 92001 to 92003 dishes. The records are those of the official sample 卡牌选择器, byte for byte; seen in play 2026-10-14 (examples/cards). Its words show on an account of 奇匠 level 2 and up. Writes a new .gil in the workspace.

Input Schema

NameRequiredDescriptionDefault
nameYes
cardsYes
titleNo
canFoldNo
mapPathNo
secondsNo
showTimeNo
canGiveUpNo
outputNameNo
warnSecondsNo
revealUnknownNo
pauseWhenAloneNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Far exceeds the annotations: annotations only say destructive/not-read-only, while the description discloses that it writes a new .gil, the exact window contents (title, countdown, cards row, 放弃选择/确认选择), the two graph hook points for input and completion, the default-on nature of the four flags, the level-start timing bug, playtest click sequences, and an account-level gating requirement ('奇匠 level 2 and up'). This is unusually rich behavioral context with no contradiction of the destructiveHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is largely valuable but delivered as a dense run-on with parenthetical Chinese terms, dated sample references, byte-for-byte provenance and an icon catalog that will rarely affect a call. It is front-loaded with the core purpose, but the middle paragraphs bury operational rules (graph hooks, timing bug) inside prose rather than organizing them.

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 12-param mutation tool with no output schema and no schema descriptions, the description covers the important behavior: what gets written, how the selector is driven by graphs, when it fails to appear, and default flag values. The only notable omissions are the auxiliary params (outputName, mapPath, warnSeconds, revealUnknown) that affect file placement and warning timing.

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 0%, so the description must carry the load, and it does explain cards (the {title, description, icon, label} vs {unknown:true, label} shapes), seconds, canGiveUp, canFold, pauseWhenAlone and showTime. However, five parameters — name, title, mapPath, outputName, warnSeconds and revealUnknown — are never explained in prose, leaving a substantial gap toward the 12-param surface.

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 ('Add a card selector ... to a copy of a save') and immediately scopes what the selector is (a platform window where a player picks cards). It is distinct from every sibling in the list (no other deck/card tool exists), so an agent can identify it unambiguously.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

Gives concrete usage conditions: the selector 'stands in no layout', only appears when a graph opens it via f.invokeDeckSelector, and must not be opened in the first seconds of a level (with empirical evidence of the failure at second 3 vs success at second 14). No explicit alternatives are named, but there are no rival card-selector tools, so the guidance is functionally complete.

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

Deploy Server

Other Tools