Skip to main content
Glama
astroway

astroway-mcp

Official
by astroway

Marseille: Timing

astroway_tarot_marseille_timing
Read-onlyIdempotent

Draw a Marseille tarot timing card to clarify when a situation or event is likely to occur, using your question and optional seed for a reproducible reading.

Instructions

Single timing card.

[Group: Tarot: Marseille] [Endpoint: POST /v1/tarot/marseille/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.3/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered; the description adds genuinely new behavioral facts in the cost (10 credits, Tier 1) and the HTTP endpoint. It does not explain how the timing determination works, what time horizon the card maps to, or how seed/question alter the result.

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?

Extremely short and front-loaded, but the bulk of the text is boilerplate metadata (group, endpoint, cost) rather than substantive purpose or usage content. Nothing is padded, yet almost nothing is said.

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?

An output schema exists so return values need no explanation, but with 4 optional params at 25% coverage, no usage routing among dozens of tarot siblings, and no explanation of what a 'timing' draw produces, the definition is under-specified for correct invocation.

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% — just 'art' is described; seed, question and allowReversed have no schema descriptions. The description contributes nothing about them, so an agent cannot tell whether 'question' should be a timing question or a general one, or what 'allowReversed' means for a timing draw.

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

Purpose2/5

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

"Single timing card" essentially restates the name (timing card) and the title, with no verb or object stated: it never says it draws/selects a Marseille card for a timing question. It also fails to distinguish from close siblings such as astroway_tarot_marseille_draw_single and astroway_tarot_rider_waite_timing.

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 use this versus the many Marseille draw variants or the Rider-Waite timing sibling. The only routing signal is the bracketed group/endpoint metadata, which the agent already gets from the tool name.

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