Skip to main content
Glama
PistachioPony

The Fortuneteller's Hand

by PistachioPony
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

Draw Goal Card

draw_goal_card

Draw one face-up card from the combined suit piles to reveal the Goal after all four cross cards are dealt, then ask the player for its meaning. Use this when the four drives have been drawn and the character is described.

Instructions

Deal the Goal: draw one card face-up from whatever's left across all four suit piles, once all four drives have been drawn.

Call once, during the Sitting, right after all four calls to
draw_cross_card are done (one per drive: Motivation, Seek, Carry, Ends)
and the player has described their character. Unlike draw_cross_card,
this draws from the combined remainder of all four suit piles at once,
not one specific suit — and it's revealed to the player immediately,
not held back. After dealing it and asking what it means, pass the
player's answer to record_goal_interpretation.

Takes no parameters. Raises ValueError if called before all four cross
positions are filled, or if a Goal has already been dealt this Sitting.
Not idempotent: mutates the shared Goal and the relevant suit pile.
Returns the drawn card as a dict with rank, suit, suit_name, domain,
rank_meaning, and phrase.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, the description discloses error conditions ('Raises ValueError if called before all four cross positions are filled, or if a Goal has already been dealt'), non-idempotency, mutation of shared state, and the return shape. This goes well beyond what readOnlyHint and destructiveHint already reveal, and it does not contradict the annotations.

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

Conciseness5/5

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

Each sentence adds necessary information: sequencing, comparison to draw_cross_card, error preconditions, state mutation, and return fields. The description is detailed but not padded, and it is organized in short scannable paragraphs.

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?

Since there is no output schema and stateful game rules matter, the description fills an important gap by specifying the returned dict fields, exact call timing, before-conditions, and post-call handoff. No essential operational detail appears missing.

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?

The tool has zero parameters and no required fields, so the schema is already complete. The description explicitly confirms 'Takes no parameters' and instead places invocation correctness on preconditions and state, which is the appropriate level of guidance for a 0-parameter tool.

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 action: 'draw one card face-up from whatever is left across all four suit piles' and clearly identifies the goal-card purpose. It also distinguishes itself from draw_cross_card by noting the combined-pile behavior and immediate reveal, which prevents sibling confusion.

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 precise sequencing: call once during the Sitting, after all four draw_cross_card calls, and after the player has described their character. It also explicitly contrasts with draw_cross_card and directs the next step to record_goal_interpretation, giving clear when-to-use and next-action guidance.

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

Install Server

Other Tools