What can you do with this server?

A professional bilingual Tarot MCP server offering complete Rider-Waite-Smith deck interpretations with advanced analytics and visual interaction. * Card Information: Retrieve detailed meanings (upright/reversed), symbolism, astrology, numerology for any of the 78 cards. Search by keyword, suit, element, arcana, or number; find similar cards; get random draws. * Readings & Spreads: Access 25+ built-in spreads (Celtic Cross, Relationship Cross, Career Path, Moon Phase, Daily Guidance, etc.) with context-aware interpretations. Create custom spreads (1–15 positions) with AI assistance. * Visual Two-Stage Drawing: Interactive web app at /draw for choosing opaque card backs, then revealing identities and orientations upon confirmation. * Analysis Tools: Compare 2–5 cards for combined messages; elemental balance, archetypal patterns, and energy flow insights. AI-powered spread recommendation based on question, category, and timeframe. * Session Management: Track reading history, persist sessions, and maintain continuity across multiple readings. * Multi-Language Support: Full English and Simplified Chinese output for card info, search, and recommendations. * Technical Features: MCP integration (stdio/HTTP/SSE), REST API, Docker deployment, authentication (MCP_AUTH_TOKEN), rate limiting, CORS, and database analytics.

How do I use Tarot MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Tarot MCP Server do a Celtic Cross reading about my career path this year" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Tarot MCP Server

by fzlzjerry

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

🔮 Tarot MCP Server

A Model Context Protocol (MCP) server and interactive React app for bilingual tarot readings, built with Node.js and TypeScript. It combines modern Rider-Waite-Smith interpretation data with a complete original midnight-art-nouveau-v1 visual deck generated for this repository.

Server config

{
  "command": "npx",
  "args": ["tarot-mcp-server@latest"],
  "env": {
    "NODE_ENV": "production"
  }
}

Related MCP server: Tarot MCP Server

🚀 Current Implementation Status

✅ FULLY IMPLEMENTED AND WORKING:

Complete 78-card Rider-Waite-Smith deck with detailed modern interpretations
Visual two-stage drawing: the server prepares 78 opaque card backs, the user chooses them in order, and identities/orientations are revealed only after confirmation
MCP App + Web app: the same accessible React/Vite table is embedded through ui://tarot-mcp/visual-reading.html and served at /draw
Original 78-card artwork: dark-night Art Nouveau faces plus a rotationally symmetric back, with Web and lightweight MCP variants
25 professional tarot spreads including Celtic Cross, Relationship Cross, Career Path, Spiritual Guidance, Year Ahead, Chakra Alignment, Shadow Work, NEW: Daily Guidance, Yes/No, Weekly Forecast, Moon Phase spreads, Elemental Balance, Past Life Karma, Compatibility
Custom Spread Creation: AI can create custom tarot spreads when existing ones don't fit
Lunar Integration: Moon phase detection with appropriate spreads and guidance
AI Spread Recommendations: Intelligent spread suggestions based on question analysis
Daily Card Practice: Single card draws for daily guidance
Card Comparison Tools: Multi-card meaning analysis and interpretation
Multi-transport MCP server (stdio, Streamable HTTP, legacy SSE)
Advanced interpretation engine with elemental analysis
Cryptographically secure card shuffling and drawing
Context-aware meaning selection
Professional-grade HTTP API with CORS support
Docker containerization with health checks
Comprehensive search and analytics tools
Session management and reading history
Full TypeScript implementation with strict typing
Vitest testing framework setup

✨ Features

🃏 Professional Tarot System

Interactive Card Choice: fan-shaped browsing, ordered spread placement, undo/reselect, sequential reveal, card details, and dedicated iconic layouts
Four Visual Workflows: built-in spreads, daily guidance, frozen moon-phase readings, and custom 1–15 card spreads
Modern RWS Meanings: User-visible card keywords and meanings follow modern Rider-Waite-Smith interpretation patterns
Complete Rider-Waite-Smith Deck: Comprehensive card database with detailed meanings, symbolism, astrology, and numerology
25 Professional Spreads: Celtic Cross, Relationship Cross, Career Path, Spiritual Guidance, Chakra Alignment, Year Ahead, Daily Guidance, Yes/No, Weekly Forecast, Moon Phase spreads, Elemental Balance, Past Life Karma, Compatibility, and more
Custom Spread Creation: AI can create unlimited custom spreads (1-15 positions) when existing spreads don't fit the specific question or context
Lunar Integration: Automatic moon phase detection with themed spreads and guidance for each lunar cycle
AI Spread Recommendations: Intelligent analysis of questions to recommend the most appropriate spread with confidence scoring
Specialized Reading Analysis: Tailored interpretations for relationships, career, spiritual growth, and energy balancing
Intelligent Card Combinations: Multi-dimensional analysis including elemental balance, suit patterns, and numerical progressions

🧠 Advanced Interpretation Engine

Context-Aware Readings: Automatically selects relevant meanings based on question content (love, career, health, spiritual)
Elemental Analysis: Fire, Water, Air, Earth balance assessment and missing element identification
Archetypal Patterns: Major Arcana progression analysis and Fool's Journey insights
Position Dynamics: Celtic Cross relationship analysis aligned to the registered spread positions
Energy Flow Assessment: Three Card spread progression and overall reading energy analysis

🚀 Technical Excellence

Multi-Transport Support: stdio, MCP Streamable HTTP, and legacy SSE protocols
Cryptographic Randomness: Fisher-Yates shuffle with crypto-secure random number generation
50/50 Fair Distribution: Equal probability for upright and reversed card orientations
Production Ready: Docker containerization, health checks, and comprehensive error handling
Session Management: Advanced context tracking and reading history
RESTful API: Direct HTTP endpoints for seamless integration
Type Safety: Full TypeScript implementation with strict typing

🎯 Live Reading Example

Here's what a professional Celtic Cross reading looks like:

{
  "question": "What should I know about my career path this year?",
  "cards": [
    {
      "position": "Present Situation",
      "card": "The Emperor (upright)",
      "meaning": "Leadership opportunities and career advancement"
    },
    {
      "position": "Challenge",
      "card": "The Lovers (reversed)",
      "meaning": "Misaligned career choices or workplace conflicts"
    },
    {
      "position": "Foundation",
      "card": "Ace of Wands (upright)",
      "meaning": "Creative spark and new opportunities"
    }
    // ... 7 more cards
  ],
  "analysis": {
    "elementalBalance": "Strong Fire energy suggests action and creativity needed",
    "positionDynamics": "Conscious goals align with subconscious drives",
    "energyFlow": "Progression from challenge to resolution",
    "guidance": "Trust your leadership abilities while addressing relationship conflicts"
  }
}

Key Features Demonstrated:

✅ Context-aware interpretations (career-focused meanings)
✅ Position relationship analysis (conscious vs subconscious)
✅ Elemental balance assessment (Fire energy dominance)
✅ Professional guidance and actionable insights

🔮 Professional Tarot Spreads

Our server features 25 specialized tarot spreads designed for different life areas and spiritual practices:

🔮 General Guidance

Single Card: Daily guidance and quick insights
Three Card: Past/Present/Future analysis with energy flow
Celtic Cross: Comprehensive 10-card life analysis
Horseshoe: 7-card situation guidance with obstacles and advice

💕 Relationships & Personal

Relationship Cross: 7-card relationship dynamics analysis

🚀 Career & Life Path

Career Path: 6-card professional development guidance
Decision Making: 5-card choice evaluation and guidance
Year Ahead: 13-card annual forecast with monthly insights

🧘 Spiritual & Energy Work

Spiritual Guidance: 6-card spiritual development and higher self connection
Chakra Alignment: 7-card energy center analysis and healing
Shadow Work: 5-card psychological integration and growth

Each spread includes:

Specialized Analysis: Tailored interpretation methods for each spread type
Position Dynamics: Understanding relationships between card positions
Energy Assessment: Elemental balance and flow analysis
Professional Guidance: Actionable insights and spiritual wisdom

🏆 Why Choose This Tarot Server?

Feature	This Server	Basic Tarot APIs	Generic Card Readers
Modern RWS Meanings	✅ Contextual modern RWS meanings	❌ Generic meanings	❌ Simplified interpretations
Advanced Analysis	✅ Elemental, numerical, archetypal	❌ Basic card meanings	❌ Single-layer interpretation
Context Awareness	✅ Question-specific meanings	❌ One-size-fits-all	❌ Generic responses
Professional Spreads	✅ Celtic Cross dynamics	❌ Simple layouts	❌ Basic positioning
MCP Integration	✅ Native MCP + HTTP/SSE	❌ HTTP only	❌ Limited protocols
Production Ready	✅ Docker, health checks, monitoring	❌ Basic deployment	❌ Development-focused
Type Safety	✅ Full TypeScript	❌ JavaScript only	❌ Minimal typing

🚀 Quick Start

Local Development

Clone and Install

git clone https://git.moraxcheng.me/Morax/tarot-mcp.git
cd tarot-mcp
npm install

Build the Project
```
npm run build
```
npm run build compiles the server, type-checks/builds the Web and single-file MCP apps, and copies the canonical card data plus both artwork sizes into dist/. Do not use bare tsc for production builds because the runtime also requires these generated assets.
Run as MCP Server (stdio)
```
npm start
# or
node dist/index.js
```
When a local stdio client does not advertise MCP Apps support for text/html;profile=mcp-app, the default auto fallback starts a temporary 127.0.0.1 loopback card table and opens it in the system browser. The page resumes the exact pending draw through a short-lived, draw-scoped handoff token; it does not shuffle or begin a second reading.
In this browser-fallback path, begin_visual_reading is a long-running tools/call: after the table URL has been opened or delivered in a progress notification, the original call remains pending while the user selects cards. Browser confirmation completes that same call with the confirmed reading, so the MCP host gives the result back to the AI and conversation resumes without a second user message. Progress heartbeats are emitted every 15 seconds while waiting, but a client may still enforce its own hard tool-call timeout.

Run as HTTP Server

npm run start:http
# or
node dist/index.js --transport http --port 3000

Development Mode

npm run dev:http  # HTTP server with hot reload
npm run dev       # stdio server with hot reload

Open the visual Web app
```
http://127.0.0.1:3000/draw
```
If MCP_AUTH_TOKEN is configured, enter it under Connection settings. The browser keeps it in sessionStorage only.

Docker Deployment

Quick Deploy with Script
```
chmod +x deploy.sh
./deploy.sh
```
Manual Docker Build
```
npm run docker:build
npm run docker:run
```

Docker Compose

npm run docker:compose
# or
docker compose up -d

📡 API Endpoints

When running in HTTP mode, the following endpoints are available:

Health & Info

GET /health - Health check with service status
GET /api/info - Server information, capabilities, and available tools

Tarot Cards

GET /api/cards - List all cards with filtering options
- ?category=all|major_arcana|minor_arcana|wands|cups|swords|pentacles
- ?language=en|zh (default: en)
GET /api/cards/:cardName - Get detailed card information
- ?orientation=upright|reversed (default: upright)
- Accepts English names, Chinese names, or stable card ids
- ?language=en|zh (default: en)

Professional Readings

POST /api/reading - Perform a comprehensive tarot reading

{
  "spreadType": "single_card|three_card|celtic_cross|...",
  "question": "Your specific question here",
  "sessionId": "optional - use the Session ID returned by a previous reading",
  "language": "optional - en or zh"
}

POST /api/custom-spread - Create and perform a custom tarot spread

{
  "spreadName": "Your Custom Spread Name",
  "description": "What this spread explores",
  "positions": [
    {
      "name": "Position Name",
      "meaning": "What this position represents"
    }
  ],
  "question": "Your specific question",
  "sessionId": "optional - use the Session ID returned by a previous reading",
  "language": "optional - en or zh"
}

GET /api/spreads?language=en|zh - List all available spread types with descriptions
POST /api/visual-readings - Prepare an opaque two-stage visual draw (readingKind: spread, daily, moon, or custom)
POST /api/visual-readings/:drawId/confirm - Confirm ordered slot IDs and reveal exactly one idempotent reading
POST /api/tools/:toolName - Invoke any MCP tool over REST using the request body as its arguments. This provides HTTP parity for search, recommendations, analytics, daily/lunar readings, comparison, and session-history tools.

Visual UI and artwork

GET /draw - Shared visual reading app (public static page)
GET /assets/cards/midnight-art-nouveau-v1/:cardId.webp - 512×768 Web artwork
GET /assets/cards/midnight-art-nouveau-v1/mcp/:cardId.webp - 192×288 MCP artwork

The static UI and versioned artwork are public/cacheable. /api/*, /mcp, /sse, and /messages continue to require Bearer authentication whenever MCP_AUTH_TOKEN is set.

Advanced Features

Celtic Cross Analysis: 10-card comprehensive reading with position dynamics
Three Card Flow: Past/Present/Future with energy progression analysis
Elemental Balance: Automatic analysis of Fire, Water, Air, Earth energies
Context-Aware Interpretations: Meanings selected based on question content
Advanced Card Search: Multi-criteria search with keyword, suit, element, and arcana filtering
Similarity Analysis: Find cards with related meanings and themes
Database Analytics: Comprehensive statistics and quality metrics
Secure Randomization: Cryptographically secure card drawing and shuffling

MCP Protocol

POST /mcp - MCP Streamable HTTP client-to-server endpoint with session initialization
GET /mcp - MCP Streamable HTTP server-to-client stream for an initialized session
DELETE /mcp - MCP Streamable HTTP session termination
GET /sse - Legacy Server-Sent Events endpoint for older MCP clients
POST /messages?sessionId=... - Legacy SSE client-to-server message endpoint advertised by /sse

🛠️ MCP Tools

The server provides 16 MCP tools. The authoritative, always-current catalog (schemas, annotations, output schemas) is served by the protocol itself — call tools/list over MCP, or GET /api/info over HTTP.

Tool	Purpose
`get_card_info`	Full card detail (meanings, symbolism, astrology)
`list_all_cards`	Card catalog, filterable by category
`list_available_spreads`	Spread catalog with positions
`perform_reading`	Reading with a built-in spread (session-aware)
`begin_visual_reading`	Prepare a hidden deck; browser fallback waits for confirmation
`confirm_visual_reading`	App-only ordered confirmation; retries return the same reading
`create_custom_spread`	Reading with a user-defined spread
`get_daily_card`	One-shot daily guidance draw
`get_moon_phase_reading`	Lunar-phase-aligned reading
`search_cards`	Multi-criteria card search
`find_similar_cards`	Cards with related meanings
`get_random_cards`	Random draws with filters
`recommend_spread`	Spread recommendation for a question
`get_card_meanings_comparison`	Compare 2-5 cards in a context
`get_database_analytics`	Card-database statistics
`get_session_history`	Summaries of a session's readings

All user-facing tools accept language: "en" | "zh" (default en) for localized Simplified Chinese output. Card lookup and search also accept Chinese card names and Chinese keywords, while spread recommendation recognizes common Chinese question phrases. Reading tools additionally return machine-readable structuredContent (reading id, session id, drawn cards) beside the Markdown text. MCP card records contain only semantic reading data: canonical name, stable cardId, localized displayName, orientation, position, keywords, and selected meaning. They do not attach imageUri, embedded image bytes, cardImages, or backImage to the model's tool result. Opaque slots alone stay in begin-result _meta; the single-file MCP App bundles its own lightweight artwork, while REST/Web responses retain their versioned static imageUri values.

The server also exposes MCP resources (tarot://cards, tarot://cards/{id}, tarot://spreads, tarot://spreads/{type}) and the MCP App resource ui://tarot-mcp/visual-reading.html using text/html;profile=mcp-app, plus prompts (perform-reading, daily-draw).

🔧 Configuration

Command Line Options

node dist/index.js [options]

Options:
  --transport <type>    Transport type: stdio, http, sse (default: stdio)
  --port <number>       Port for HTTP/SSE transport (default: $PORT or 3000)
  --host <address>      Bind address for HTTP transport (default: $HOST or 0.0.0.0)
  --help, -h           Show help message

Environment Variables

Variable	Purpose
`PORT` / `HOST`	HTTP listener port and bind address
`MCP_AUTH_TOKEN`	When set, MCP/REST endpoints require `Authorization: Bearer <token>`; `/health`, `/draw`, and versioned artwork stay public. Set this for any public deployment.
`ALLOWED_ORIGINS`	Comma-separated browser origins allowed beyond localhost (`*` allows any)
`ALLOWED_HOSTS`	When set, requests must carry one of these Host headers
`RATE_LIMIT_MAX` / `RATE_LIMIT_WINDOW_MS`	Rate limit per IP (default 120 requests / 60s)
`MCP_MAX_TRANSPORT_SESSIONS`	Cap on concurrent transport sessions per transport (default 100)
`SESSION_STORE_PATH`	When set, reading sessions persist to this JSON file and survive restarts/redeploys (24h idle expiry still applies). Docker Compose enables it by default (`/data/sessions.json` on a named volume); without it sessions are memory-only and a restart invalidates existing sessionIds.
`TAROT_BROWSER_FALLBACK`	Local stdio visual-delivery mode: `auto` opens the browser only when the client does not declare MCP Apps HTML support; `off` disables browser handoff; `force` always opens the loopback table; `link` returns the handoff link without launching a browser. Default: `auto`. HTTP/SSE modes never launch a browser on the server host.
`TAROT_BROWSER_FALLBACK_PORT`	Loopback handoff listener port for stdio browser fallback. Default: `0`, which asks the OS for an available random port.
`LOG_LEVEL` / `LOG_FORMAT`	`debug

🎯 MCP Client Integration

Cursor IDE

Add to your Cursor mcp.json:

{
  "mcpServers": {
    "tarot": {
      "command": "npx",
      "args": ["tarot-mcp-server@latest"]
    }
  }
}

Or for local development:

{
  "mcpServers": {
    "tarot": {
      "command": "node",
      "args": ["/path/to/tarot-mcp/dist/index.js"]
    }
  }
}

ChatWise

For a local ChatWise stdio entry, enable both Auto run and Long running:

Name: tarot
Type: STDIO
Command: /opt/homebrew/bin/node /Users/moraxcheng/tarot-mcp/dist/index.js
Environment: TAROT_BROWSER_FALLBACK="auto"
Auto run: On
Long running: On

ChatWise may refresh its MCP registry when focus returns from the system browser. Some releases send the stdio child SIGTERM during that refresh even though the browser-backed tools/call is still pending. When the connected client identifies itself as ChatWise, Tarot MCP defers that lifecycle signal only while a browser confirmation waiter is active, returns the confirmed result to the original call, allows stdout to drain, and then exits normally. A real ChatWise process exit still terminates the handoff immediately.

No additional HTTP server entry is needed for a local stdio client. If the client declares the MCP Apps extension with the text/html;profile=mcp-app MIME type, the table remains embedded in the client. Otherwise, TAROT_BROWSER_FALLBACK=auto opens an ephemeral http://127.0.0.1:PORT/draw/#handoff=... page. The fragment token attaches that browser tab to the already prepared drawId, supports idempotent confirmation and refresh recovery, and is not used by HTTP/SSE server transports. Once the URL is opened automatically or delivered through MCP progress, the original begin_visual_reading call remains pending. The server sends progress heartbeats while waiting; confirming in the browser returns the confirmed reading from that same call, which gives the AI a normal tool result and resumes the host turn.

Keep the MCP client connected until confirmation: the stdio process owns the in-memory draw and loopback listener. Progress resets cooperative MCP timeouts, but some clients impose a shorter hard maximum that heartbeats cannot extend. A client that neither launches the browser nor exposes progress cannot receive a URL while the call is pending; in link mode the compatibility behavior is to return the pending draw with the URL immediately. A host may half-close stdin after dispatching the call while it continues reading stdout; the pending browser waiter deliberately keeps the loopback process alive until confirmation, cancellation, or the draw's 30-minute expiry. A real MCP transport close, SIGINT, or ordinary SIGTERM still stops the listener, while request cancellation releases that request's waiter reference. The one compatibility exception is ChatWise's registry-refresh SIGTERM during an active browser waiter, described above. If the client process itself terminates, the page reports the disconnect and a new draw must be started.

The embedded MCP App uses a different continuation contract. Its initial begin_visual_reading returns the pending draw immediately so the host can render the App. After the App calls confirm_visual_reading, it publishes the confirmed structured reading through the host's model-context bridge and requests a host message when those MCP App capabilities are available. That new host turn lets the AI continue from the selected cards. The bridge contains only card ids, names, orientations, positions, keywords, meanings, and interpretation text; it never forwards image URLs, base64 artwork, or image content blocks. Hosts without those capabilities still show the completed reading in the App but may require the user to continue the conversation manually.

Streamable HTTP MCP Clients

For clients supporting MCP Streamable HTTP:

{
  "mcpServers": {
    "tarot": {
      "url": "http://localhost:3000/mcp"
    }
  }
}

Legacy SSE MCP Clients

For older clients supporting the legacy Server-Sent Events transport:

{
  "mcpServers": {
    "tarot": {
      "url": "http://localhost:3000/sse"
    }
  }
}

The legacy /sse endpoint advertises /messages?sessionId=... as the matching client-to-server message endpoint.

Streamable HTTP and legacy SSE deployments do not automatically open the default browser on the machine running the server. Their users continue to use the embedded MCP App when supported or the explicitly hosted /draw Web page.

📚 Usage Examples

Professional Reading Examples

Single Card Daily Guidance

curl -X POST http://localhost:3000/api/reading \
  -H "Content-Type: application/json" \
  -d '{
    "spreadType": "single_card",
    "question": "What energy should I embrace today?"
  }'

Features: Elemental analysis, daily guidance, spiritual insights

Three Card Relationship Reading

curl -X POST http://localhost:3000/api/reading \
  -H "Content-Type: application/json" \
  -d '{
    "spreadType": "three_card",
    "question": "How can I improve my relationships?"
  }'

Features: Past/Present/Future flow, energy progression analysis

Celtic Cross Career Reading

curl -X POST http://localhost:3000/api/reading \
  -H "Content-Type: application/json" \
  -d '{
    "spreadType": "celtic_cross",
    "question": "What should I know about my career path this year?"
  }'

Features: 10-card comprehensive analysis, position dynamics, conscious vs subconscious insights

Relationship Cross Analysis

curl -X POST http://localhost:3000/api/reading \
  -H "Content-Type: application/json" \
  -d '{
    "spreadType": "relationship_cross",
    "question": "How can I improve my relationship with my partner?"
  }'

Features: 7-card relationship dynamics, compatibility assessment, unity/division analysis

Career Path Guidance

curl -X POST http://localhost:3000/api/reading \
  -H "Content-Type: application/json" \
  -d '{
    "spreadType": "career_path",
    "question": "What should I know about my career development?"
  }'

Features: 6-card professional analysis, skills assessment, opportunity identification

Chakra Energy Alignment

curl -X POST http://localhost:3000/api/reading \
  -H "Content-Type: application/json" \
  -d '{
    "spreadType": "chakra_alignment",
    "question": "How can I balance my energy centers?"
  }'

Features: 7-card chakra analysis, energy balance assessment, spiritual healing guidance

Custom Spread Creation

curl -X POST http://localhost:3000/api/custom-spread \
  -H "Content-Type: application/json" \
  -d '{
    "spreadName": "AI Decision Making Spread",
    "description": "A custom spread designed to help AI make decisions when no existing spread fits the situation",
    "positions": [
      {
        "name": "Current Situation",
        "meaning": "The present state of affairs that needs to be addressed"
      },
      {
        "name": "Hidden Influences",
        "meaning": "Unseen factors affecting the situation"
      },
      {
        "name": "Option A",
        "meaning": "One potential direction or choice"
      },
      {
        "name": "Option B",
        "meaning": "An alternative direction or choice"
      },
      {
        "name": "Guidance",
        "meaning": "Wisdom and advice for making the best decision"
      }
    ],
    "question": "What is the best approach for creating a new tarot spread when existing ones don'\''t fit?"
  }'

Features: Unlimited custom spread creation (1-15 positions), AI-driven card drawing, position-specific interpretations

Two-stage visual reading

curl -X POST http://localhost:3000/api/visual-readings \
  -H "Content-Type: application/json" \
  -d '{
    "readingKind": "spread",
    "spreadType": "three_card",
    "question": "What should I understand next?",
    "language": "en"
  }'

Choose the required opaque slotId values from the returned 78-card deck in the desired position order, then confirm once:

curl -X POST http://localhost:3000/api/visual-readings/DRAW_ID/confirm \
  -H "Content-Type: application/json" \
  -d '{"selectedSlotIds":["SLOT_1","SLOT_2","SLOT_3"]}'

Card Information Queries

Detailed Card Information

curl "http://localhost:3000/api/cards/The%20Fool?orientation=upright"

Browse Cards by Category

curl "http://localhost:3000/api/cards?category=major_arcana"
curl "http://localhost:3000/api/cards?category=wands"

List Available Spreads

curl "http://localhost:3000/api/spreads"

Advanced Search and Analytics

The /mcp endpoint is a full MCP Streamable HTTP transport. Raw HTTP clients must first send an initialize request, keep the returned mcp-session-id, then send notifications/initialized before calling tools. MCP clients handle this automatically.

Search Cards by Keyword

curl -X POST http://localhost:3000/mcp \
  -H "Accept: application/json, text/event-stream" \
  -H "Content-Type: application/json" \
  -H "mcp-session-id: <initialized-session-id>" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
      "name": "search_cards",
      "arguments": {
        "keyword": "love",
        "suit": "cups",
        "limit": 5
      }
    }
  }'

Find Similar Cards

curl -X POST http://localhost:3000/mcp \
  -H "Accept: application/json, text/event-stream" \
  -H "Content-Type: application/json" \
  -H "mcp-session-id: <initialized-session-id>" \
  -d '{
    "jsonrpc": "2.0",
    "id": 3,
    "method": "tools/call",
    "params": {
      "name": "find_similar_cards",
      "arguments": {
        "cardName": "The Lovers",
        "limit": 3
      }
    }
  }'

Get Database Analytics

curl -X POST http://localhost:3000/mcp \
  -H "Accept: application/json, text/event-stream" \
  -H "Content-Type: application/json" \
  -H "mcp-session-id: <initialized-session-id>" \
  -d '{
    "jsonrpc": "2.0",
    "id": 4,
    "method": "tools/call",
    "params": {
      "name": "get_database_analytics",
      "arguments": {
        "includeRecommendations": true
      }
    }
  }'

Get Random Cards for Practice

curl -X POST http://localhost:3000/mcp \
  -H "Accept: application/json, text/event-stream" \
  -H "Content-Type: application/json" \
  -H "mcp-session-id: <initialized-session-id>" \
  -d '{
    "jsonrpc": "2.0",
    "id": 5,
    "method": "tools/call",
    "params": {
      "name": "get_random_cards",
      "arguments": {
        "count": 3,
        "arcana": "major"
      }
    }
  }'

🏗️ Architecture

Professional Tarot Engine

src/
├── index.ts              # CLI entry point for stdio or HTTP transport
├── mcp/
│   ├── protocol-server.ts # Shared MCP protocol server and tool handlers
│   ├── http-server.ts     # Streamable HTTP, legacy SSE, and REST endpoints
│   └── tarot-service.ts   # MCP tool orchestration over tarot domain services
└── tarot/
    ├── cards/            # Card data, loading, search, and analytics
    ├── readings/         # Spreads, lunar utilities, readings, and sessions
    └── shared/           # Types, validation, and secure randomness
ui/
├── src/                  # Shared React table and Web/MCP client adapters
├── vite.web.config.ts    # /draw build
└── vite.mcp.config.ts    # Single-file MCP App build
assets/
├── cards/                # Web/MCP WebP deck, manifest, and QA sheets
└── artwork/              # Original sources and prompt provenance

Key Components

Advanced Interpretation Engine

Multi-Dimensional Analysis: Individual cards + combinations + overall themes
Modern RWS Methods: Based on Rider-Waite-Smith card structure, imagery, and modern contextual reading patterns
Context Awareness: Question-specific meaning selection (love, career, health, spiritual)
Elemental Analysis: Fire, Water, Air, Earth balance and missing element identification

Production-Ready Infrastructure

Multi-Transport Support: stdio, MCP Streamable HTTP, legacy SSE, and HTTP REST helpers
Docker Containerization: Complete deployment with health checks and monitoring
Error Handling: Comprehensive error responses and logging
Type Safety: Full TypeScript implementation with strict mode
Two-stage State Isolation: pending visual draws stay process-local and separate from persisted TarotSession history until atomic confirmation

🧪 Testing & Quality Assurance

Test Suite

# Run server + UI tests
npm run test:all

# Run tests with coverage report
npm run test:coverage

# Run tests in watch mode during development
npm run test:watch

# Code quality checks
npm run lint
npm run typecheck:ui
npm run format

# Validate the complete generated deck and packaged build
npm run verify:assets
npm run build
npm run verify:build

Quality Metrics

Unit Tests: Card manager, reading logic, and interpretation engine
Integration Tests: immediate/visual REST and MCP flows, hidden metadata, idempotency, authentication, and static UI boundaries
UI Tests: ordered selection, staging, reveal, details, localization, layouts, Web auth, and MCP metadata normalization
Artwork Validation: 78 IDs plus back, dimensions, hashes, size ceilings, pip metadata, duplicate detection, symmetry, and contact sheets
Type Safety: 100% TypeScript with strict mode enabled
Code Coverage: Comprehensive test coverage for core functionality
Modern RWS Validation: Interpretations are tested against modern RWS semantic anchors and card imagery checks

Research Validation

Accuracy Verification: Data tests verify deck order, schema strictness, modern RWS anchors, and generated-asset manifests
RWS Compliance: Adherence to the 78-card Rider-Waite-Smith deck structure
Professional Standards: Implementation of methods used by certified tarot readers
Symbolic Integrity: Proper interpretation of traditional symbols and imagery

🚢 Deployment

Production Deployment

Build for production

npm run build
npm run verify:assets
npm run verify:build

Run with PM2 (recommended)

npm install -g pm2
pm2 start dist/index.js --name tarot-mcp -- --transport http --port 3000

Or use Docker

docker run -d -p 3000:3000 --name tarot-mcp tarot-mcp

Reverse Proxy Setup

Example Nginx configuration:

server {
    listen 80;
    server_name your-domain.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

📄 License

MIT License - see LICENSE file for details.

🤝 Contributing

We welcome contributions to improve the Tarot MCP Server! Here's how you can help:

🎯 Priority Areas

Enhanced Interpretations: Deeper psychological analysis and Jungian insights
Timing Predictions: Advanced timing predictions and seasonal influences
Internationalization: Support for multiple languages and cultural variations
Visual Integration: Card imagery and visual representation support
Mobile Integration: React Native or Flutter SDK development

📋 Contribution Process

Fork the repository and create a feature branch
Keep meanings modern RWS - User-visible card meanings must remain aligned with modern Rider-Waite-Smith semantics
Maintain quality - Follow TypeScript best practices and include comprehensive tests
Document changes - Update README and add examples for new features
Submit pull request with detailed description and test coverage

🔬 Research Standards

Primary Basis: Rider-Waite-Smith deck structure, card imagery, and modern RWS semantic anchors
Verification: Update modern-rws-fixtures.ts and data integrity tests when card meanings change
RWS Accuracy: Maintain adherence to the 78-card Rider-Waite-Smith deck and modern interpretation language
Professional Language: Use authentic tarot terminology and phrasing

🧪 Testing Requirements

Unit Tests: All new functionality must include comprehensive tests
Integration Tests: API endpoints and MCP tool validation
Type Safety: Maintain 100% TypeScript coverage with strict mode
Documentation: Include usage examples and API documentation

🗺️ Roadmap

📅 Version 2.0 (Planned)

Enhanced Interpretations: Deeper psychological analysis and Jungian insights
Timing Predictions: Seasonal influences and time-based guidance
Enhanced AI: Machine learning for pattern recognition in readings
Visual Integration: Card imagery and interactive visual representations

📅 Version 2.5 (Future)

Multi-Language Support: Internationalization for global accessibility
Cultural Variations: Support for different tarot traditions and interpretations
Advanced Analytics: Reading history analysis and personal growth tracking
Mobile SDK: Native mobile application support

📅 Version 3.0 (Vision)

Psychological Integration: Advanced Jungian analysis and psychological tarot methods
Real-Time Collaboration: Shared readings and collaborative interpretation
AI-Enhanced Insights: Advanced pattern recognition and personalized guidance
Blockchain Integration: Decentralized reading verification and authenticity

🔮 About This Modern RWS Tarot Implementation

Modern RWS Accuracy

This server implements the Rider-Waite-Smith tarot deck with modern user-visible interpretations:

Modern RWS Semantics: Card meanings use contemporary keywords and context-specific explanations
RWS Imagery: Descriptions and symbolism stay grounded in recognizable Rider-Waite-Smith card art
Historical Awareness: Classical correspondences inform metadata without overriding modern user-visible meanings
Reader Methods: Advanced combination interpretation techniques for context-aware readings

Comprehensive Card Database

✅ COMPLETE: All 78 cards of the Rider-Waite-Smith deck are fully implemented with extensive information for each card:

Multi-Context Meanings: General, love, career, health, and spiritual interpretations
Orientation Specific: Detailed upright and reversed meanings beyond simple opposites
Symbolic Analysis: Comprehensive interpretation of Rider-Waite-Smith imagery
Astrological Correspondences: Planetary and zodiacal associations
Numerological Significance: Spiritual and practical number meanings
Elemental Associations: Fire, Water, Air, Earth energies and their interactions

Advanced Reading Methods

Celtic Cross Dynamics: Professional 10-card analysis with position relationships
Three Card Flow: Energy progression and temporal analysis
Elemental Balance: Missing element identification and recommendations
Archetypal Patterns: Major Arcana progression and spiritual themes
Context Awareness: Question-specific meaning selection and relevance

Professional Quality

The interpretations maintain traditional tarot wisdom while providing:

Authentic Language: Professional tarot terminology and phrasing
Actionable Guidance: Practical advice combined with spiritual insights
Depth and Nuance: Multi-layered analysis beyond surface meanings
Accessibility: Clear explanations suitable for both beginners and experienced readers

Available Tools

14 tools

create_custom_spreadA

Create a custom tarot spread and draw cards for it. Use this when no existing spread fits your needs and you want to create your own layout with specific positions and meanings.

ParametersJSON Schema

Name	Required	Description	Default
`language`	No	Output language (default: en)	en
`question`	Yes	The question or focus for this reading
`positions`	Yes	Array of position objects defining each card position in the spread
`sessionId`	No	Optional session ID returned by a previous reading; omit to start a new session
`spreadName`	Yes	Name for your custom spread
`description`	Yes	Description of what this spread is designed to explore

Output Schema

ParametersJSON Schema

Name	Required	Description
`cards`	Yes
`question`	Yes
`readingId`	Yes
`sessionId`	No	Present when the reading is tracked in a session
`timestamp`	Yes	ISO 8601
`spreadName`	Yes
`spreadType`	Yes

TDQS

A4/5.0

Behavior3/5

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

Annotations are minimal (readOnlyHint=false, idempotentHint=false). The description adds that the tool draws cards, indicating a write/creation action. It does not contradict annotations. However, it does not detail side effects like session creation or storage, so its behavioral disclosure is adequate but not extensive.

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?

The description is two sentences long, both front-loaded with the action and usage guidance. Every sentence adds value without wasted words. It is concise and well-structured.

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?

Given the presence of an output schema (mentioned in context signals), the description does not need to explain return values. It covers the tool's purpose and usage context adequately for a creation tool. However, it could mention that the tool also draws cards and possibly initiates a session, but overall it is quite complete.

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 description coverage is 100%, so every parameter has a description in the schema. The tool description adds no additional parameter details beyond 'specific positions and meanings' which is already implied by the schema. Therefore, the description does not significantly enhance parameter understanding beyond the schema.

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 clearly states the tool creates a custom spread and draws cards for it. It specifies the action verb 'Create' and the resource 'custom tarot spread', and distinguishes it from using existing spreads.

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

Usage Guidelines4/5

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

The description explicitly says when to use this tool: 'when no existing spread fits your needs'. This distinguishes it from sibling tools like list_available_spreads or recommend_spread. It implies not to use if a standard spread suffices, though it doesn't explicitly list exclusions.

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

find_similar_cardsA

Read-onlyIdempotent

Find cards with similar meanings to a given card

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of similar cards to return (default: 5)
`cardName`	Yes	The name of the card to find similar cards for

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already convey read-only and idempotent behavior. The description adds no further behavioral context such as error handling, result limits (already in schema), or the definition of 'similar meanings'. It is adequate but does not go beyond 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?

The description is a single, front-loaded sentence of 11 words that clearly communicates the tool's purpose without any extraneous information.

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 simple, read-only tool with complete schema and annotations, the description is nearly complete. It could mention the output format or definition of similarity, but the core functionality is well covered.

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 100%, so the schema already describes both parameters (cardName and limit). The description does not add any additional semantic information about the parameters beyond what is in the schema.

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 clearly states the verb 'Find' and resource 'cards' with the qualifier 'with similar meanings to a given card'. It distinguishes from siblings like 'search_cards' (general search) and 'get_card_meanings_comparison' (comparison of two specific cards).

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?

No explicit when-to-use or when-not-to-use guidance is provided. The description only states what the tool does, with no mention of alternatives or context for choosing this tool over siblings like 'get_card_meanings_comparison' or 'search_cards'. The usage is implied from the name and description.

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

get_card_infoA

Read-onlyIdempotent

Get detailed information about a specific tarot card from the Rider-Waite deck

ParametersJSON Schema

Name	Required	Description	Default
`cardName`	Yes	The name of the tarot card (e.g., 'The Fool', 'Two of Cups')
`language`	No	Output language (default: en)	en
`orientation`	No	The orientation of the card (upright or reversed)	upright

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds no further behavioral context beyond 'get detailed information', which is consistent. No disclosure of potential rate limits, response size, or data structure.

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?

Single sentence, front-loaded with verb and resource. No wasted words, efficient and clear.

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?

Adequate for a simple info retrieval tool with well-documented parameters and annotations. However, lacks specifics on what 'detailed information' includes (e.g., meanings, symbols), which would be helpful given no output schema.

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 100% with clear descriptions for all three parameters. Description does not add additional meaning beyond schema, but baseline 3 is appropriate.

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?

Clearly states action (get detailed information), resource (specific tarot card), and source (Rider-Waite deck). Distinguishes from siblings like list_all_cards, search_cards, get_card_meanings_comparison.

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?

Implied usage for fetching detailed info on a single card, but no explicit when-to-use or when-not-to-use guidance, nor alternatives mentioned. Adequate but not explicit.

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

get_card_meanings_comparisonA

Read-onlyIdempotent

Compare 2-5 tarot cards, including optional card orientation, to understand their relationships and combined message

ParametersJSON Schema

Name	Required	Description	Default
`cards`	No	Preferred input: array of 2-5 card objects with names and optional orientations
`context`	No	The context or question for interpreting these cards together
`language`	No	Output language: "en" or "zh" (default: en)	en
`cardNames`	No	Legacy input: array of 2-5 card names, interpreted as upright

TDQS

A4.1/5.0

Behavior4/5

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

The description clarifies that the tool compares cards and outputs a combined message, which aligns with annotations (readOnlyHint, idempotentHint). No contradictions; adds context beyond the annotations by describing the output purpose.

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?

The description is a single, clear sentence that front-loads the core action (compare cards) with key details (2-5, optional orientation, output purpose). No wasted words.

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?

The description is complete for this tool: it covers the main use case, parameters are well-documented in schema, annotations provide safety hints, and no output schema exists to explain return values. Nothing essential is missing.

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 description coverage is 100%, so the schema already documents all parameters. The description does not add new semantics beyond summarizing the function, achieving baseline with no additional parameter-level detail.

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 clearly states the tool compares 2-5 tarot cards with optional orientation to understand relationships and combined message. It distinguishes from siblings like get_card_info (single card) and get_random_cards (random selection).

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?

The description implies usage for comparing cards but does not explicitly state when to use this tool versus alternatives like perform_reading or recommend_spread. No when-not-to-use guidance is provided.

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

get_daily_cardA

Read-only

Draw a single card for daily guidance and insight

ParametersJSON Schema

Name	Required	Description	Default
`language`	No	Output language (default: en)	en
`question`	No	Optional specific question for daily guidance	What do I need to know for today?

Output Schema

ParametersJSON Schema

Name	Required	Description
`cards`	Yes
`question`	Yes
`readingId`	Yes
`sessionId`	No	Present when the reading is tracked in a session
`timestamp`	Yes	ISO 8601
`spreadName`	Yes
`spreadType`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the description's addition of 'single card' and 'daily guidance' provides some context but no further behavioral traits like randomness or state dependence. No contradiction with 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?

Single sentence, no redundancy, front-loaded with action and context.

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?

Given the tool's simplicity (2 optional params, read-only, output schema exists), the description sufficiently covers the purpose and usage context. No major gaps.

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 100% and descriptions are provided for both parameters. The tool description adds no extra semantics beyond the schema, so baseline 3 is appropriate.

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 clearly states the action 'Draw a single card' and the context 'daily guidance and insight', distinguishing it from siblings like 'get_random_cards' (multiple cards) and 'perform_reading' (spread-based).

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?

The description implies usage for daily guidance but gives no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.

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

get_database_analyticsA

Read-onlyIdempotent

Get comprehensive analytics and statistics about the tarot card database

ParametersJSON Schema

Name	Required	Description	Default
`includeRecommendations`	No	Whether to include improvement recommendations (default: true)

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds no behavioral insights. It neither contradicts nor significantly extends 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?

A single, front-loaded sentence that conveys the tool's purpose without any extraneous text. Every word is necessary.

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?

Given the tool's simplicity (one optional param, no output schema, strong annotations), the description is minimally adequate. However, it does not elaborate on what statistics or analytics are provided, which could be important for agent decision-making.

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?

Input schema has 100% coverage for the single optional parameter, so the schema already documents its meaning. The description does not add any parameter-specific context.

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 clearly states the tool's function with a specific verb ('Get') and resource ('comprehensive analytics and statistics about the tarot card database'), which is distinct from all sibling tools.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or when it would be inappropriate to use.

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

get_moon_phase_readingB

Read-only

Perform a tarot reading based on the current moon phase with an appropriate spread

ParametersJSON Schema

Name	Required	Description	Default
`language`	No	Output language (default: en)	en
`question`	Yes	Your question or intention for the moon phase reading
`customDate`	No	Optional custom date in YYYY-MM-DD format (defaults to today)

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the read-only nature is clear. The description adds that the reading is moon-phase-based and uses an appropriate spread, providing some behavioral context but not extensive details beyond 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?

The description is a single concise sentence with no redundancy, efficiently conveying the tool's purpose.

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?

Given the absence of an output schema and the complexity of a tarot reading, the description should explain what the reading returns (e.g., card names, interpretation). It does not, leaving critical information gaps.

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?

Input schema has 100% description coverage, so the description adds little extra meaning. It does not clarify that customDate overrides the moon phase date, leaving ambiguity.

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 clearly states it performs a tarot reading based on the moon phase with an appropriate spread, which is specific and distinguishes it from siblings like 'perform_reading' and 'get_daily_card'.

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 is provided on when to use this tool versus alternatives such as 'perform_reading' or 'get_daily_card'. The description lacks context on preferred use cases or exclusions.

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

get_random_cardsB

Read-only

Get random cards with optional filtering

ParametersJSON Schema

Name	Required	Description
`suit`	No	Filter by card suit
`count`	No	Number of random cards to draw (default: 1)
`arcana`	No	Filter by arcana type
`element`	No	Filter by element

TDQS

B3.4/5.0

Behavior3/5

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

The description does not contradict annotations (readOnlyHint=true). It adds minimal behavioral context beyond 'random' and 'optional filtering', but the annotations already indicate a safe read operation. No side effects or additional behaviors are disclosed.

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?

The description is a single, efficient sentence that conveys the core functionality without unnecessary words. It could be slightly expanded to include more context without becoming verbose, but it remains concise.

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?

Given the simplicity of the tool and the presence of annotations, the description is mostly adequate. However, it lacks information about the return format or what constitutes a 'card' object, which would be helpful without an output schema.

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?

With 100% schema coverage, the baseline is 3. The description summarizes the parameters as 'optional filtering', which adds little beyond the schema. It does not provide specific details about each parameter beyond what is already in the schema.

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 clearly states the action ('Get random cards') and the resource ('cards'), with optional filtering. It effectively distinguishes the tool from siblings like 'list_all_cards' and 'search_cards', which serve different purposes.

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?

The description provides no explicit guidance on when to use this tool versus alternatives, such as 'search_cards' for specific queries or 'list_all_cards' for a complete listing. The context of 'random' is implied but not elaborated.

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

get_session_historyA

Read-onlyIdempotent

List the readings performed so far in a session (summaries with spread, question, time, and drawn cards)

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes	The session ID returned by a previous reading

Output Schema

ParametersJSON Schema

Name	Required	Description
`createdAt`	Yes	ISO 8601
`sessionId`	Yes
`readingCount`	Yes
`storedReadings`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

Annotations declare readOnlyHint=true and idempotentHint=true, and the description adds context that it returns summaries with specific fields. However, it does not describe error handling, pagination, or limits. The description adds some value beyond annotations but not comprehensive.

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?

The description is a single sentence that directly conveys purpose and content. It is front-loaded with the verb and resource, with no redundant information. Efficient but could benefit from more structure.

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?

Given the tool's simplicity (one parameter) and presence of an output schema, the description adequately conveys what the tool returns. It specifies the fields in summaries, so the agent has a good idea of the output. Missing details about empty sessions or limits, but overall complete.

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 100%; the only parameter 'sessionId' is described in the schema as 'The session ID returned by a previous reading'. The description does not add additional semantics for the parameter beyond this, so baseline of 3 is appropriate.

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 clearly states the verb 'List' and the resource 'readings performed so far in a session', specifying the content of summaries. It distinguishes from sibling tools like perform_reading (which creates a reading) and get_card_info (which retrieves card details).

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 explicit guidance on when to use this tool vs alternatives, such as when a session exists or how to obtain a sessionId. The description only states what it does, without prerequisites or exclusions.

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

list_all_cardsA

Read-onlyIdempotent

List all available tarot cards in the Rider-Waite deck

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Filter cards by category	all

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and idempotentHint, so the description adds the deck specificity but no additional behavioral insights beyond that. No contradictions.

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?

One clear sentence, no fluff, front-loaded with the core action. Perfectly concise.

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 simple list tool with one optional parameter and robust annotations, the description is sufficient. It could optionally mention output format or default behavior, but not necessary.

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?

The schema provides full description for the single parameter 'category' (enum with description), so the description does not need to add more. Baseline 3 applies due to high schema coverage.

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 clearly states the verb 'list', the resource 'available tarot cards', and specifies the deck 'Rider-Waite', which distinguishes it from sibling tools like search_cards or get_card_info.

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?

The description implicitly indicates use for getting all cards but does not provide explicit guidance on when to use this tool versus alternatives like search_cards or get_random_cards.

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

list_available_spreadsA

Read-onlyIdempotent

List all available tarot spreads with their positions and meanings

ParametersJSON Schema

Name	Required	Description	Default
`language`	No	Output language (default: en)	en

TDQS

A4/5.0

Behavior4/5

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

The description states the tool 'List all available spreads', which aligns with the readOnlyHint=true and idempotentHint=true annotations. It adds value by specifying that positions and meanings are included, going beyond the annotations alone.

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?

The description is a single, front-loaded sentence with no wasted words. It immediately identifies the action and resource.

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?

Despite lacking an output schema, the description provides enough context by stating the tool returns spreads with positions and meanings. Given the tool's simplicity (one optional parameter), the description is reasonably complete for an AI agent.

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?

The schema coverage is 100% (single parameter 'language' with enum and default). The description does not mention the language parameter, but the schema already fully describes it. Baseline of 3 is appropriate since no additional semantics are added.

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 uses the specific verb 'List' and identifies the resource as 'available tarot spreads' with the detail 'with their positions and meanings', which clearly distinguishes it from sibling tools like 'get_daily_card' or 'recommend_spread'.

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?

The description implies usage for browsing spreads but provides no explicit guidance on when to use this tool versus alternatives like 'recommend_spread' or 'create_custom_spread'. The context signals show no required parameters, suggesting simple usage, but the lack of when-not usage is a gap.

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

perform_readingC

Perform a tarot card reading using a specific spread

ParametersJSON Schema

Name	Required	Description	Default
`language`	No	Output language (default: en)	en
`question`	Yes	The question or focus for the reading
`sessionId`	No	Optional session ID returned by a previous reading; omit to start a new session
`spreadType`	Yes	The type of tarot spread to perform

Output Schema

ParametersJSON Schema

Name	Required	Description
`cards`	Yes
`question`	Yes
`readingId`	Yes
`sessionId`	No	Present when the reading is tracked in a session
`timestamp`	Yes	ISO 8601
`spreadName`	Yes
`spreadType`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

Annotations indicate this is not read-only (readOnlyHint: false) and not idempotent, but the description adds no additional behavioral context. It does not disclose side effects, state changes, or return format beyond the schema. With sparse annotations, the description should provide more transparency.

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?

The description is a single, front-loaded sentence with no waste. It is concise but could be more informative without losing brevity.

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?

Given the complexity of tarot readings (many spread types, session handling, language options) and that an output schema exists, the description is incomplete. It does not explain session behavior, output structure, or how to interpret results, leaving significant gaps.

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 100%, so baseline is 3. The description only adds 'using a specific spread', which does not clarify the meaning of parameters like question, sessionId, or language beyond what the schema already provides.

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?

The description clearly states the action ('perform') and the resource ('tarot card reading') and mentions the key parameter ('using a specific spread'). However, it does not distinguish this tool from siblings like get_daily_card or list_available_spreads, which could be alternatives for obtaining readings or card information.

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?

There is no guidance on when to use this tool versus alternatives. The description does not specify prerequisites, when not to use it, or how it compares to sibling tools such as get_daily_card or recommend_spread.

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

recommend_spreadA

Read-onlyIdempotent

Get a recommendation for the most appropriate tarot spread based on your question or situation

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	The category of your question	any
`language`	No	Output language (default: en)	en
`question`	Yes	Your question or description of the situation you want guidance on
`timeframe`	No	The timeframe you're asking about	any

Output Schema

ParametersJSON Schema

Name	Required	Description
`category`	Yes
`question`	Yes
`timeframe`	Yes
`recommendations`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, but the description adds no additional behavioral context such as how the recommendation is made, limitations, or what the output contains. The description merely restates the purpose without enriching the behavioral understanding beyond 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?

A single, well-structured sentence of 15 words immediately conveys the tool's purpose. Every word earns its place, there is no redundancy, and the key action and resource are front-loaded.

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?

Given the complexity (4 parameters, output schema exists but not detailed in description), the description is minimally adequate. It does not explain how to interpret the recommendation or what output to expect, but the existence of the output schema somewhat compensates. Sibling differentiation is not addressed, leaving some context gaps.

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 description coverage is 100%, so the baseline is 3. The description does not mention any parameters, but the schema already adequately describes each parameter's meaning, so no additional value is provided.

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 uses the specific verb 'Get a recommendation' and identifies the resource as 'the most appropriate tarot spread', clearly distinguishing from sibling tools like 'list_available_spreads' (which just lists) and 'create_custom_spread' (which creates).

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

Usage Guidelines4/5

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

The description provides clear context that the tool is used 'based on your question or situation', implying it is for selecting a spread. However, it lacks explicit guidance on when not to use it or alternatives, which prevents a higher score.

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

search_cardsA

Read-onlyIdempotent

Search for tarot cards using various criteria like keywords, suit, element, etc.

ParametersJSON Schema

Name	Required	Description
`suit`	No	Filter by card suit
`limit`	No	Maximum number of results to return (default: 10)
`arcana`	No	Filter by arcana type
`number`	No	Filter by card number
`element`	No	Filter by element
`keyword`	No	Search keyword to find in card meanings, keywords, or symbolism
`orientation`	No	Search in upright or reversed meanings

Output Schema

ParametersJSON Schema

Name	Required	Description
`results`	Yes
`showing`	Yes
`totalMatches`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds no extra behavioral details (e.g., pagination, response format) beyond mentioning search criteria.

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?

The description is a single, clear sentence that front-loads the core purpose. It is appropriately concise, though a bit more structure (e.g., mentioning default limit) could improve clarity.

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?

Given the complexity (7 parameters, output schema exists), the description is functional but minimal. It lacks details on how filters combine (AND/OR) and assumes the agent knows default behavior. The output schema covers return values, so completeness is adequate.

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 description coverage is 100%, so the schema already documents all parameters. The description merely echoes the parameter list without adding new semantic meaning, meeting the baseline of 3.

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 clearly states the verb 'search' and the resource 'tarot cards', and lists example criteria like keywords, suit, and element. It distinguishes itself from sibling tools such as 'find_similar_cards' and 'get_random_cards' by being a general search tool.

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?

The description implies usage for searching cards with filters but does not explicitly state when to use this tool versus alternatives like 'list_all_cards' or 'find_similar_cards'. No 'when not to use' guidance is provided.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose, from card info to reading types to analytics. While some tools involve drawing cards, their contexts (daily, moon phase, custom spread, general reading) are well-defined and described.

Naming Consistency5/5

All tools follow a consistent snake_case verb_noun pattern (e.g., get_card_info, perform_reading, list_available_spreads), making the naming predictable and easy to interpret.

Tool Count5/5

14 tools cover the domain thoroughly without being excessive. Each tool serves a specific need in tarot reading, from database exploration to personalized readings.

Completeness4/5

The tool set covers core tarot functionalities: card info, various reading types, spread management, search, and history. Minor gaps like advanced filtering or reading notes exist but do not hinder primary use cases.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

equiblesagent-mcp
com.clauxel.equiblesagent
A paid remote MCP for Equibles, built to return verdicts, receipts, usage logs, and audit-ready JSON
Finance Legal & Compliance
2
skybridgepackager-mcp
com.clauxel.skybridgepackager
A paid remote MCP for Skybridge, built to return verdicts, receipts, usage logs, and audit-ready JSO
Security Observability
2
zerolangcompiler-mcp
com.clauxel.zerolangcompiler
A paid remote MCP for ZeroLang, built to return verdicts, receipts, usage logs, and audit-ready JSON
Developer Tools Code Analysis Monitoring
2
fastmcpruntime-mcp
com.clauxel.fastmcpruntime
A paid remote MCP for hosted MCP server, built to return verdicts, receipts, usage logs, and audit-r
Agent Orchestration Monitoring
2

Related MCP Servers

Fortune MCP Server
Entertainment & Media
takada-at
F
license
B
quality
D
maintenance
Enables users to perform tarot card readings and generate horoscopes based on specified dates, times, and locations. Provides mystical divination services through tarot draws and astrological calculations.
Updated a year ago (2025-08-14 10:30 UTC)
2
Tarot MCP Server
Art & Culture Search
abdul-hamid-achik
A
license
A
quality
C
maintenance
Provides tarot card reading capabilities with a complete 78-card deck, multiple spread layouts (Celtic Cross, Past-Present-Future, etc.), and detailed card interpretations for divination and daily guidance.
Updated a year ago (2025-08-28 03:59 UTC)
9
19
5
MIT
tarot-mcp-server
Entertainment & Media
gokimedia
A
license
Not graded
quality
A
maintenance
Provides tarot card meanings, spreads (three-card, yes/no), and random draws for any MCP-compatible client.
Updated 7 days ago (2026-08-27 16:49 UTC)
19
2
MIT
Asking Fate MCP Server
Art & Culture
Armulee
A
license
Not graded
quality
B
maintenance
Provides fortune-telling tools including tarot card spreads, Thai horoscope, zodiac info, and auspicious dates. Enables interactive tarot card picking via an MCP App UI and returns structured JSON for interpretation.
Updated 2 months ago (2026-07-06 00:12 UTC)
2,013
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fzlzjerry/tarot-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server