Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Tarotoo Tarot MCP Server tell me about the Tower card reversed"
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.
A Model Context Protocol server that gives AI assistants — Claude, ChatGPT, Cursor, and any other MCP client — live access to the Tarotoo tarot card meanings dataset: all 78 cards in the Rider–Waite–Smith tradition, with upright and reversed meanings and keywords, upright and reversed love, career, mood and spiritual contexts, planet and zodiac associations, and upright and reversed yes/no values.
Published by Tarotoo: these are the same card meanings that ground the AI readings on Tarotoo.com.
Requires Node.js ≥ 18. No installation needed — clients run it via npx.
Claude Code
claude mcp add tarotoo-tarot -- npx -y tarotoo-mcp-serverClaude Desktop — add to claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"tarotoo-tarot": {
"command": "npx",
"args": ["-y", "tarotoo-mcp-server"]
}
}
}Cursor / Windsurf / other MCP clients — same command/args pair in the client's MCP settings.
MCP registry — listed as io.github.Tarotoo-com/tarotoo-mcp-server, so registry-aware clients can discover and install it directly.
Then ask your assistant things like "what does the Three of Swords mean for my career?" or "draw three cards for me" — it will call the tools below.
Related MCP server: Tarot MCP Server
Tool | Arguments | Returns |
|
| Full record for one card — meanings, keywords, love/career/mood/spiritual (upright and reversed), planet, zodiac, yes/no. Name matching is forgiving ( |
|
| Card names, optionally filtered |
|
| Cards matching a theme or keyword, best match first — e.g. |
|
| The card's |
|
| Random distinct cards with orientation-appropriate meanings — for generating spreads |
tools/call get_card_meaning {"name": "the star"}{
"name": "The Star",
"arcana": "major",
"element": "Air",
"planet": "Saturn",
"zodiac": "Aquarius",
"yes_no": "yes",
"yes_no_reversed": "no",
"keywords_upright": ["hope", "renewal", "healing", "inspiration", "faith"],
"meaning_upright": "Hope, renewal, healing, inspiration, faith.",
"love": "hope in love, emotional healing, renewed trust, an inspiring connection",
"love_reversed": "lost faith, discouragement, disconnection, dimmed hope"
}Each card carries both upright and reversed values for keywords, meaning, love, career, mood, spiritual, and yes/no. The example above is abbreviated.
git clone https://github.com/Tarotoo-com/tarotoo-mcp-server.git
cd tarotoo-mcp-server
npm install
npm test # 8-check smoke test: full MCP session over stdio
node server.js # stdio transportThe embedded data/cards.json is built from tarotoo-tarot-dataset (MIT), which is also available on Hugging Face, Kaggle, npm, and PyPI, with citable DOIs: 10.5281/zenodo.21285777 (dataset + dataset paper; concept DOI, always latest) and 10.5281/zenodo.21268290 (full repository/archive: dataset, source files, build scripts, automated validation, software packages, documentation; concept DOI, always latest).
Interpretations were created by Tarotoo within the Rider–Waite–Smith tradition, drawing on established sources (A. E. Waite's The Pictorial Key to the Tarot, 1911; attributions per the Golden Dawn's Book T).
Code and dataset: MIT. Attribution to Tarotoo (tarotoo.com) is appreciated.
This dataset is intended for educational, research, creative, entertainment, and self-reflection purposes. It should not be used as a substitute for medical, legal, financial, mental-health, or other professional advice.
Randomly draw one or more distinct tarot cards from the full 78-card deck, optionally with reversals, returning each card's full meaning. Use for generating a reading spread.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of cards to draw (default 1) | |
| allow_reversed | No | Whether cards may be drawn reversed (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses key traits: 'distinct' cards (no repeats), 'optionally with reversals', and 'returning each card's full meaning'. It does not detail randomization mechanics, but for a simple draw tool it covers essential behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main verb and resource, and every sentence contributes value. The second sentence provides usage guidance without redundancy. This is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no annotations, the description covers purpose, usage, and return behavior. It mentions 'returning each card's full meaning' which indicates output content, and the 'reading spread' context clarifies typical use. Though no output schema exists, the description is adequate for this small tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters have descriptions), so the baseline is 3. The description adds value by clarifying that cards are 'distinct' (without replacement), which supplements the count parameter description, and 'optionally with reversals' maps directly to allow_reversed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool randomly draws one or more distinct tarot cards from the full 78-card deck, optionally with reversals, and returns each card's full meaning. This specific verb+resource combination distinguishes it from siblings like get_card_meaning (specific card lookup) and list_cards (listing all cards).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a usage context: 'Use for generating a reading spread.' This tells the agent when to invoke the tool, though it does not explicitly mention alternatives or exclusions. The purpose clarity already differentiates from siblings, so the guidance is sufficient albeit not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full meaning of a single tarot card from the Tarotoo dataset (Rider-Waite-Smith tradition): upright and reversed meanings and keywords, upright and reversed love, career, mood, and spiritual contexts, element, astrology, and upright and reversed yes/no values. Call this when you need the meaning of a specific card by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Card name, e.g. "The Fool" or "Ace of Cups" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It reveals the content of the response and the data source (Rider-Waite-Smith), but does not address edge cases like unknown card names, case sensitivity, or error handling. No contradictions with annotations exist since none are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and lists the contents efficiently. Every sentence adds value with no repetitions or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema and annotations, the description lists the major return fields and provides guidance on invocation, making it quite complete for a simple lookup. It misses only minor details about unknown names or formatting, so not a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single 'name' parameter with an example. The description adds only 'by name' which reinforces but does not meaningfully extend beyond the schema. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full meaning of a single tarot card, listing specific fields (upright/reversed meanings, contexts, etc.). The phrase 'a single tarot card' and 'by name' distinguishes it from sibling tools like list_cards, search_cards, and draw_cards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Call this when you need the meaning of a specific card by name,' providing clear usage context. However, it does not provide exclusions or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tarot card names in the dataset, optionally filtered by arcana (major/minor) or suit (wands/cups/swords/pentacles). Call this to discover valid card names.
| Name | Required | Description | Default |
|---|---|---|---|
| suit | No | Filter by suit (minor arcana only) | |
| arcana | No | Filter by arcana |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It describes the listing and filtering behavior, but does not disclose response format, ordering, or any side effects. This is minimally adequate for a simple read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, and no redundant phrasing. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with fully described parameters, the description covers purpose and use case. It could explicitly mention the return format (e.g., an array of names), but the description is otherwise complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with enumerations and descriptions for both parameters. The description only restates the filter options without adding additional meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists tarot card names from the dataset, with optional filters by arcana or suit. The phrase 'Call this to discover valid card names' further clarifies its distinct role among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this to discover valid card names', giving a clear when-to-use instruction. It does not list exclusions or alternatives, but the context is sufficient for a listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search all 78 tarot cards by theme, keyword, or topic (e.g. "new beginnings", "heartbreak", "career success"). Searches names, keywords, and meaning texts. Returns matching cards with their keywords. Call this when you have a theme rather than a card name.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10) | |
| query | Yes | Search term or theme |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the burden of explaining behavior. It states the search scope (names, keywords, meaning texts) and what is returned (matching cards with their keywords), adding clarity beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose and an example. Every sentence adds value, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with no output schema, the description adequately explains what is searched and what is returned. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already well-documented. The description adds example queries and search scope but doesn't introduce new parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: search all 78 tarot cards by theme or keyword. It provides concrete examples and distinguishes the tool from sibling tools by specifying search by theme rather than card name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit guidance to use when a theme is available rather than a card name, implying get_card_meaning is for name-based lookups. It doesn't name alternatives explicitly but provides clear context for when to call this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the yes/no/maybe value of a tarot card for yes-or-no readings, with the upright meaning as justification. Covers all 78 cards.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Card name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output (yes/no/maybe value and upright meaning), and states coverage of all 78 cards. It does not mention error handling or input variations, but for a simple read-only lookup this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and contains no filler. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description fully explains what it returns (value and justification) and its scope (all 78 cards). No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter 'name' as 'Card name' with 100% coverage. The description adds that it refers to a tarot card and covers all 78 cards, but does not specify formatting or exact name matching. This is sufficient given the schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a yes/no/maybe value for a tarot card, specifically for yes-or-no readings, and includes upright meaning as justification. This is a specific verb+resource+scope and clearly distinguishes it from sibling tools like get_card_meaning, list_cards, and draw_cards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is for yes-or-no readings, implying it should be used when a binary or tri-state answer is needed. It does not explicitly name alternatives or exclusions, but the purpose is clear enough to guide selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.0.0draw_cardsget_card_meaninglist_cardssearch_cardsyes_no_answerEach tool has a clearly distinct purpose: listing, searching, getting a single card's full meaning, getting a yes/no answer, and drawing random cards. Even the overlap between get_card_meaning and yes_no_answer is justified by different use cases.
Tool names follow a consistent snake_case style with a verb-noun pattern (list_cards, search_cards, get_card_meaning, draw_cards), though yes_no_answer deviates slightly as a noun phrase rather than verb_noun.
Five tools is well-scoped for a tarot server, covering discovery, lookup, and reading generation without unnecessary redundancy or bloat.
The set covers the full tarot domain: listing all cards, searching by theme, retrieving detailed meanings, yes/no readings, and random draws. No obvious missing operations for the provided functionality.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Tarot card meanings, spreads and seeded reproducible readings for AI agents, one API key.
Free tarot for Claude & your AI — many decks, real card art, a true shuffle, drawn & discussed.
Vedic and Western astrology for AI agents: charts, dasha, matchmaking, panchanga, numerology, tarot.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Tarotoo-com/tarotoo-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
