Skip to main content
Glama
astroway-mcp

astroway-mcp

Official
by astroway

RWS: Timing Card

astroway_tarot_rider_waite_timing
Read-onlyIdempotent

Draw a single Rider-Waite-Smith tarot card to determine timing for a question. Customize card art, seed, and reversed card settings.

Instructions

Single timing card to indicate when.

[Group: Tarot: Rider-Waite-Smith] [Endpoint: POST /v1/tarot/rider-waite/timing] [Cost: 10 credits (Tier 1)]

Input Schema

NameRequiredDescriptionDefault
artNoCard art set, e.g. rws-1909, rws-restored, rws-vector. GET /v1/tarot/decks lists the sets per deck.
seedNo
questionNo
allowReversedNo

Output Schema

NameRequiredDescriptionDefault
seedNo
typeNo
drawnNo
spreadNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful operational context (POST endpoint, 10-credit Tier 1 cost), but says nothing about how the seed parameter affects determinism/reproducibility of the draw.

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?

Very short and front-loaded, with the core purpose stated first and metadata grouped below. Nothing is wasted, though the same brevity is the source of its under-specification.

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

Completeness2/5

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

With 4 parameters at 25% schema coverage, an output schema, and no ambiguity about return format, the description still leaves the agent without enough to call it confidently: no indication of what 'question' does or how 'allowReversed' changes the timing interpretation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 25%: 'art' is documented, while 'seed', 'question' and 'allowReversed' have no schema descriptions. The description adds no meaning for any parameter — it doesn't explain that question shapes the reading or that seed makes the draw reproducible — so it fails to compensate for the low coverage.

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

Purpose3/5

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

The description names a specific resource ('Single timing card') and its intent ('to indicate when'), which gives a rough sense that this draws one card to answer a timing question. However, 'indicate when' is vague about what the result actually is (a season, a date range, a planetary hour?) and it never distinguishes itself from siblings like astroway_tarot_rider_waite_outcome or _advice.

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

Usage Guidelines2/5

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

No guidance on when to choose this timing draw versus the many other RWS tarot tools, nor on prerequisites such as whether a question is required. The only usage-adjacent content is endpoint and cost metadata.

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