Asterwise

Tarot Card of the Day

asterwise_get_tarot_card_of_the_day

Read-onlyIdempotent

Returns a deterministic daily tarot card seeded by SHA-256 hash of the date string. The same card is returned for all callers on the same date — this is intentional. The daily card is not a reading for an individual but a collective daily energy.

WORKFLOW: BEFORE: None — standalone. AFTER: asterwise_get_tarot_three_card_spread — for deeper daily reading context.

INPUT CONTRACT: date (optional string YYYY-MM-DD) — Date to get the card for. Defaults to today's date in UTC, or in timezone. Overrides timezone. Example: '2026-05-01' allow_reversed (optional bool) — Default: false. When true: reversed state is also deterministic (seeded by date+'_rev'). When false: card is always upright regardless of date. timezone (optional, IANA or ±HH:MM, e.g. 'Asia/Kolkata') — zone whose current date is today. Default: UTC.

DO NOT CONFUSE WITH: asterwise_draw_tarot_cards — random draw, different every call. asterwise_get_tarot_three_card_spread — positional reading with question context.

Full output and error contract: https://docs.asterwise.com/mcp/tools/get-tarot-card-of-the-day/

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "asterwise_get_tarot_card_of_the_day"
  }
}

Input Schema

Name	Required	Description	Default
`date`	No	Date to get the card for, YYYY-MM-DD. Defaults to today's date in UTC, or in timezone. Overrides timezone.
`timezone`	No	IANA time zone (or ±HH:MM) whose current date counts as today, e.g. 'Asia/Kolkata'. Defaults to UTC; ignored when date is given.
`allow_reversed`	No	Whether cards may be drawn reversed (upside down).
`response_format`	No	Output format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload.	markdown

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 8, 2026

changedInput schema / properties / date / description

Previous value: -"Date in YYYY-MM-DD format. Defaults to today when omitted."New value: +"Date to get the card for, YYYY-MM-DD. Defaults to today's date in UTC, or in timezone. Overrides timezone."

addedInput schema / properties / timezone

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "IANA time zone (or ±HH:MM) whose current date counts as today, e.g. 'Asia/Kolkata'. Defaults to UTC; ignored when date is given."
+}

Changed3 schema fields changedSep 5, 2026

addedInput schema / properties / allow_reversed / description

Added value: +"Whether cards may be drawn reversed (upside down)."

addedInput schema / properties / date / description

Added value: +"Date in YYYY-MM-DD format. Defaults to today when omitted."

addedInput schema / properties / response_format / description

Added value: +"Output format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload."

Changed2 schema fields changedSep 4, 2026
- addedInput schema / properties / response_format / default
```
Added value: +"markdown"
```
- removedInput schema / required
```
Removed value: -[
-  "response_format"
-]
```
AddedMay 1, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, closed-world. The description adds genuinely non-obvious behavior: determinism via SHA-256, the intentional shared-card-across-callers design, the collective-vs-individual framing, and the allow_reversed seeding quirk (date+'_rev'). Return-format details are deferred to an external doc link rather than described inline.

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?

Structured with labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE) and front-loaded with the core definition. Slightly verbose in places (redundant restatement of timezone behavior between date and timezone lines; external doc link is not self-contained) but nearly all content carries signal.

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 4-param read-only tool with full schema coverage and an output schema, the description covers purpose, routing, determinism semantics, and parameter precedence. The main gap is that output/error contract is externalized to a URL, which an agent cannot resolve inline, but the output schema mitigates this.

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?

Schema coverage is 100%, so baseline is 3. The description still adds value beyond schema: the date-vs-timezone precedence (date overrides timezone), the reversed-state seeding logic when allow_reversed is true vs. false, and an example date string. The response_format param is only documented in the schema, not the description.

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 (Returns) and resource (daily tarot card) with precise mechanics (SHA-256 seeded by date, deterministic, same for all callers). Explicitly distinguishes it from asterwise_draw_tarot_cards (random) and the three-card spread in a dedicated DO NOT CONFUSE section.

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?

Provides an explicit WORKFLOW block (BEFORE: none, standalone; AFTER: three-card spread for deeper context) and a DO NOT CONFUSE WITH section naming the two closest siblings and how they differ. When-to-use is unambiguous.

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

All Asterwise tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?