Skip to main content
Glama

draw_card

Draw a card from the deck and move into the discard phase, using the latest revision so stale actions are rejected.

Instructions

抽一张牌,之后进入弃牌阶段。

Input Schema

NameRequiredDescriptionDefault
revisionYes最新状态的 revision;过期操作会被拒绝

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose a meaningful state transition (entering the discard phase after drawing), which is real value beyond the schema. It says nothing about failure modes (stale revision rejection is only in the schema), hand-size limits, or what the tool returns.

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?

A single tightly written sentence with the action front-loaded and the consequence trailing. Nothing is wasted, though the extreme brevity leaves gaps that could have been filled cheaply.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter game action with a fully documented schema and no output schema, the description covers the core action and its follow-on phase. It stops short of stating turn/phase preconditions or error behavior, which an agent needs to invoke this reliably without trial and error.

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 description coverage is 100% — the single 'revision' parameter is documented as 'latest state revision; stale operations are rejected.' The description adds no parameter context, but the schema already does the work, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (draw a card) that is distinguishable from sibling actions like play_cards, select_cards and discard_card. It does not explicitly name those siblings or clarify the boundary, but the action itself is unambiguous.

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

Usage Guidelines3/5

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

The clause '之后进入弃牌阶段' implies the tool belongs to a draw step followed by a discard step, which weakly points the agent toward discard_card next. There is no explicit when-to-use/when-not guidance, prerequisites, or named alternatives.

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