astroway-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Generate Tarot Reading (PDF or HTML)

astroway_reports_tarot

Generate a tarot reading report as PDF, HTML, or Markdown from spreads like three-card, Celtic cross, or year-ahead. Set a seed for reproducible draws and localize the output.

Instructions

Render a tarot reading PDF. Default spread three-card (Past/Present/Future from Rider-Waite-Smith deck). Available spreads: single-card, three-card, celtic-cross, horseshoe, relationship, year-ahead, decision, chakra, career, love-triangle. Pass seed for reproducibility (deterministic mulberry32 RNG); omit to use a daily seed. Set allowReversed: false to draw upright cards only.

[Group: Reports] [Endpoint: POST /v1/reports/tarot] [Cost: 100 credits (Tier 4)]

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": "astroway_reports_tarot"
  }
}

Input Schema

Name	Required	Description
`name`	No
`seed`	No
`format`	No	`pdf` (default) stores a PDF and answers with its `url`. `html` returns one self-contained `text/html` document, `markdown` returns `text/markdown` with the same sections and tables; neither is stored. Same price in every format.
`spread`	No
`language`	No
`whitelabel`	No
`allowReversed`	No

Output Schema

Name	Required	Description	Default
`url`	No
`expires_at`	No
`page_count`	No
`byte_length`	No
`duration_ms`	No
`storage_key`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.6.1Nov 9, 2026

addedInput schema / properties / format

Added value: +{
+  "description": "`pdf` (default) stores a PDF and answers with its `url`. `html` returns one self-contained `text/html` document, `markdown` returns `text/markdown` with the same sections and tables; neither is stored. Same price in every format.",
+  "enum": [
+    "pdf",
+    "html",
+    "markdown"
+  ],
+  "type": "string"
+}

Addedv1.6.0Oct 24, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false and idempotentHint=false, and the description adds genuinely new behavioral context: a 100-credit Tier 4 cost, the POST endpoint, and — critically — that passing `seed` makes output deterministic while omitting it draws a daily seed, which directly explains the non-idempotent flag. It stops short of stating what is persisted or whether repeated calls bill again.

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?

Front-loaded with the core action and defaults, then the spread catalog, then per-parameter behavior. The spread list and the Group/Endpoint/Cost footer are dense but each line carries actionable information; no filler prose.

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?

With 7 optional parameters, an output schema, and nested whitelabel branding, the definition is only partially complete — the branding object and the language set are undocumented anywhere the agent would see them. Coverage of the core generation parameters is adequate, so it is usable but leaves real gaps for a paid, non-idempotent generation call.

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 coverage is only 14%, so the description carries substantial burden; it partially compensates by explaining `seed` semantics and the `allowReversed` toggle and by enumerating spread values. It says nothing about `name`, `language` (21 locales), `whitelabel`, or `format`, and even lists names like "love-triangle" and "chakra" without describing required inputs for those spread variants.

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+resource ("Render a tarot reading PDF") and enumerates the ten supported spreads plus the default deck, so an agent knows exactly what artifact it gets. It does not differentiate itself from siblings like astroway_ai_interpret_tarot or astroway_tarot_decks, and the leading "PDF" framing is narrower than the actual format enum (pdf/html/markdown) hinted at by the title.

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?

Gives useful in-tool guidance (default spread, seed for reproducibility, allowReversed toggle) but never states when to choose this report over the sibling tarot tools, nor any prerequisites. Usage is implied by the parameter notes rather than by an explicit when/when-not statement.

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

Deploy Server