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 draw a daily card for guidance" 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 abdul-hamid-achik

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Tarot MCP Server

codecov npm version License: MIT Node.js Version

A Model Context Protocol (MCP) server that provides tarot card reading capabilities to AI assistants like Claude, Cursor, and other MCP-compatible tools.

Features

Complete 78-card Tarot deck with Major and Minor Arcana
Multiple spread layouts including Celtic Cross, Past-Present-Future, and more
Card interpretations with upright and reversed meanings
Intelligent readings with contextual interpretation
Search functionality to find cards by keywords
Daily card draws for daily guidance

Related MCP server: Tarot MCP Server

Installation

From npm

npm install -g tarot-mcp

From source

git clone https://github.com/yourusername/tarot-mcp.git
cd tarot-mcp
npm install
npm run build

Configuration

Claude Desktop

Add the following to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%/Claude/claude_desktop_config.json Linux: ~/.config/Claude/claude_desktop_config.json

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

If installed locally from source:

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

Cursor

Add to your Cursor settings:

Open Cursor Settings (Cmd+, on macOS, Ctrl+, on Windows/Linux)
Navigate to the "Features" tab
Look for "Model Context Protocol" or "MCP" section
Add the tarot server configuration:

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

VSCode with Continue Extension

If using the Continue extension for VSCode:

Open Continue settings (~/.continue/config.json)
Add the MCP server to the mcpServers section:

{
  "mcpServers": [
    {
      "name": "tarot",
      "command": "npx",
      "args": ["tarot-mcp"]
    }
  ]
}

Other MCP-Compatible Tools

For any tool that supports MCP servers, you generally need:

Command: npx tarot-mcp (if installed from npm) or node /path/to/dist/index.js (if local)
Transport: stdio (standard input/output)
Server Name: tarot

Check your tool's documentation for specific configuration format.

Available Tools

1. `draw_cards`

Draw a specified number of tarot cards.

Parameters:
- count (number): Number of cards to draw (1-78)

2. `perform_reading`

Perform a complete tarot reading with a specific spread.

Parameters:
- spreadId (string): ID of the spread to use
- question (string, optional): Question for the reading

3. `interpret_reading`

Get a detailed interpretation of a tarot reading.

Parameters:
- reading (object): The reading object from perform_reading

4. `get_card_meaning`

Get detailed information about a specific tarot card.

Parameters:
- cardName (string): Name of the card (e.g., "The Fool", "Three of Cups")

5. `list_spreads`

List all available tarot spreads with descriptions.

6. `get_spread_info`

Get detailed information about a specific spread.

Parameters:
- spreadId (string): ID of the spread

7. `daily_card`

Draw a single card for daily guidance.

8. `search_cards`

Search for tarot cards by keyword.

Parameters:
- query (string): Search query

9. `list_all_cards`

List all 78 tarot cards.

Parameters:
- arcana (string, optional): Filter by "major", "minor", or "all"

Available Spreads

single-card: Single Card - Quick insight or daily guidance
past-present-future: Past, Present, Future - Temporal progression
situation-action-outcome: Situation, Action, Outcome - Decision making
mind-body-spirit: Mind, Body, Spirit - Holistic self-reflection
celtic-cross: Celtic Cross - Comprehensive 10-card analysis
relationship-spread: Relationship Spread - 7-card relationship dynamics
career-spread: Career Path - 5-card career guidance
horseshoe: Horseshoe - 7-card general guidance
year-ahead: Year Ahead - 12 cards for each month
decision-making: Decision Making - 5-card decision analysis

Example Usage

In Claude Desktop

Once configured, you can ask Claude to use the tarot tools:

"Draw three tarot cards for me"

"Perform a Celtic Cross reading about my career"

"What does The Fool card mean?"

"Show me all available tarot spreads"

"Do a past-present-future reading about my relationship"

"Search for cards related to 'love'"

"Give me a daily tarot card"

In Cursor

The tarot tools will be available to the AI assistant. You can use them in:

Chat Panel: Ask the AI to perform readings or explain cards
Inline Code Generation: Request tarot-related functionality
Terminal Commands: Use the AI to help interpret readings

Example prompts:

"Use the tarot MCP server to draw a card for today"
"Perform a relationship spread reading"
"List all available tarot spreads"

In VSCode with Continue

After configuration, use commands like:

Type @tarot to specifically use the tarot server
Ask questions like "Draw a Celtic Cross spread"
Request interpretations: "What does the Three of Swords mean?"

Programmatic Usage

You can also interact with the MCP server programmatically:

// Example of calling the MCP server from your application
const reading = await mcp.call('tarot', 'perform_reading', {
  spreadId: 'celtic-cross',
  question: 'What should I focus on this month?'
});

const interpretation = await mcp.call('tarot', 'interpret_reading', {
  reading: reading
});

Development

Building

npm run build

Testing locally

npm run dev

Project Structure

tarot-mcp/
├── src/
│   ├── index.ts          # MCP server implementation
│   ├── types/            # TypeScript type definitions
│   │   └── tarot.ts
│   ├── data/            # Tarot card and spread data
│   │   ├── cards.ts
│   │   └── spreads.ts
│   └── tools/           # Tool implementations
│       └── tarot-tools.ts
├── package.json
├── tsconfig.json
└── README.md

Troubleshooting

Common Issues

Server not connecting
- Ensure the path to the server is correct
- Check that Node.js is installed and accessible
- Verify the configuration file is properly formatted JSON
Commands not working
- Restart your AI tool after adding the configuration
- Check the tool's logs for MCP connection errors
- Ensure you've built the project if running from source
"Tool not found" errors
- The AI tool might need explicit prompting to use the MCP server
- Try prefixing requests with "Use the tarot MCP server to..."

Getting Help

Check the GitHub Issues
Verify your configuration matches the examples above
Ensure you're using the latest version

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Ideas for Contribution

Add more tarot spreads
Enhance card interpretations
Add support for different tarot deck traditions
Implement card combination meanings
Add journaling features
Create visualization tools

License

MIT

Author

Abdul Hamid Achik

Acknowledgments

Tarot card meanings based on traditional Rider-Waite-Smith interpretations
Built with the Model Context Protocol SDK
Inspired by centuries of tarot tradition and modern digital divination tools

Resources

Available Tools

9 tools

daily_cardA

Draw a single card for daily guidance

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It only states 'draw a single card' without disclosing any behavioral traits like randomness, side effects, or authorization needs. Minimal disclosure.

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?

Extremely concise: one phrase with no wasted words. Front-loaded purpose.

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 no parameters, no output schema, and no annotations, the description is minimal but adequate for a simple tool. However, it could usefully indicate whether the draw is random or from a specific set.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. The description adds meaning by specifying 'for daily guidance,' which provides context beyond the empty 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 it draws a single card for daily guidance, which is a specific verb+resource combination. It distinguishes from siblings like 'draw_cards' (likely multiple) and 'perform_reading' (more complex).

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 provides no explicit when/when-not guidance or alternatives. It lacks exclusions or comparisons to sibling tools.

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

draw_cardsB

Draw a specified number of tarot cards

ParametersJSON Schema

Name	Required	Description	Default
`count`	Yes	Number of cards to draw (1-78)

TDQS

B3/5.0

Behavior2/5

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

No annotations provided; description lacks details on randomness, deck state, or side effects, which are important for a draw operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single short sentence, but lacks structure; could benefit from additional context while remaining concise.

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?

No output schema and no description of what the tool returns (e.g., card names, images), leaving agents uncertain about the response.

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 description adds no extra meaning beyond the schema description for the count parameter.

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 specifies the verb 'Draw' and the resource 'tarot cards', differentiating from siblings like 'daily_card' and 'perform_reading'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, such as for simple draws vs. complex readings.

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

get_card_meaningB

Get detailed information about a specific tarot card

ParametersJSON Schema

Name	Required	Description	Default
`cardName`	Yes	Name of the card (e.g., "The Fool", "Three of Cups")

TDQS

B3/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits, but it only vaguely says 'detailed information' without specifying what that includes or mentioning side effects, permissions, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but lacks sufficient detail to be considered optimal for an agent.

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 no output schema, the description should explain what 'detailed information' entails to set expectations; it fails to do so, making it incomplete.

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 a parameter description, so baseline is 3. The description adds no additional meaning beyond what the schema provides.

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 ('Get') and the resource ('detailed information about a specific tarot card'), distinguishing it from sibling tools like 'list_all_cards' and 'search_cards'.

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 guidelines are provided about when to use this tool versus alternatives, nor any context for prerequisites or exclusions.

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

get_spread_infoB

Get detailed information about a specific spread

ParametersJSON Schema

Name	Required	Description	Default
`spreadId`	Yes	ID of the spread

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided. Description does not disclose read-only nature, side effects, or what 'detailed information' includes. Minimal behavioral disclosure.

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 key information. No unnecessary words.

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?

For a tool with 1 parameter and no output schema, description is too brief. Does not explain what 'detailed information' includes, missing return value context.

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?

100% schema coverage, but description adds no extra meaning beyond parameter name and schema description. Baseline 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?

Description clearly states verb 'get' and resource 'detailed information about a specific spread', distinguishing it from siblings like list_spreads.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives like list_spreads or perform_reading. Context of use is implied but not explicit.

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

interpret_readingB

Get a detailed interpretation of a tarot reading

ParametersJSON Schema

Name	Required	Description	Default
`reading`	Yes	The reading object returned from perform_reading

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only says 'detailed interpretation' without explaining what that entails (e.g., AI-generated, stored database, side effects). Lacks clarity on whether the operation is read-only or requires authentication.

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 with no redundant words. It could benefit from slightly more context, but for a simple tool it is appropriately concise.

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?

The description does not explain the structure or content of the interpretation (e.g., whether it returns text, covers all cards, includes positions). No output schema exists, so the description should fill this gap but fails to do so.

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% for the single parameter 'reading', and its description in the schema is clear. The tool description adds no extra meaning, but the schema already handles the parameter definition adequately.

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 'interpret' and the resource 'tarot reading', distinguishing it from sibling tools like 'perform_reading' (which generates the reading) and 'get_card_meaning' (which focuses on individual cards).

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as 'get_card_meaning' or 'draw_cards'. It does not mention prerequisites like having performed a reading first, though the input schema implies it.

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

list_all_cardsB

List all 78 tarot cards

ParametersJSON Schema

Name	Required	Description	Default
`arcana`	No	Filter by arcana type (default: all)

TDQS

B3.4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It implies a read-only operation but does not explicitly state non-destructive behavior or other constraints. For a simple list, it is adequate but minimal.

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 that front-loads the core purpose with no unnecessary words.

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 low complexity (simple listing with one optional parameter), the description is quite complete. It covers the main action and scope, though return format is not mentioned.

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% as the parameter 'arcana' is well-documented with enum values. The description adds no additional meaning beyond the schema, so baseline score 3 is appropriate.

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?

Description states 'List all 78 tarot cards' with a specific verb and resource, which is clear. However, it does not differentiate from sibling tools like 'search_cards' that may also list cards.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as 'search_cards' or 'get_card_meaning'. The description only states what it does.

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

list_spreadsA

List all available tarot spreads

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only states it lists spreads, with no mention of read-only nature, return format, or any side effects. Minimal information for an agent to understand behavior.

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 with no wasted words. Front-loaded and appropriately sized for the tool's simplicity.

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 listing tool with no parameters and no output schema, the description is adequate. However, it could hint at the return format (e.g., names or IDs) to improve completeness. Still sufficient for the task.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has zero parameters, so description adds no parameter info. Baseline for 0 params is 4, and schema coverage is trivially 100%. No additional semantics needed.

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?

Description explicitly states the tool lists all available tarot spreads, with a specific verb and resource. It clearly distinguishes from sibling tools like 'list_all_cards' and 'get_spread_info'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like 'get_spread_info' or 'search_cards'. The description implies using it to get an overview, but lacks explicit when-to-use or when-not-to-use instructions.

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

perform_readingB

Perform a tarot reading with a specific spread

ParametersJSON Schema

Name	Required	Description	Default
`spreadId`	Yes	ID of the spread to use (e.g., "celtic-cross", "past-present-future")
`question`	No	Optional question for the reading

TDQS

B3.3/5.0

Behavior2/5

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

No annotations exist, so the description must disclose behavioral traits. It only states 'perform a reading' but omits details like whether it is read-only, if it requires authentication, or what side effects occur (e.g., does it record the reading?). This lack of transparency leaves the agent with minimal behavioral understanding.

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, succinct sentence with no unnecessary words. It is front-loaded and efficient.

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 (2 parameters, no output schema), the description is minimally adequate but lacks details on return values or constraints. For a complete picture, the agent might need to infer output format from the tool name.

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 input schema already documents both parameters. The description adds no extra meaning beyond what the schema provides. 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 ('perform') and object ('tarot reading') with a specific spread, distinguishing it from sibling tools like 'draw_cards' or 'interpret_reading'.

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 (e.g., 'draw_cards' for drawing without spread, 'get_spread_info' for spread details). The description does not indicate prerequisites or when not to use it.

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

search_cardsB

Search for tarot cards by keyword

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query (searches names, keywords, and descriptions)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, and the description lacks behavioral details such as whether results are ranked, limited, or paginated. The schema description for 'query' adds some info (searches names, keywords, descriptions), but the tool description itself is silent on behavior.

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 extremely concise at one sentence (5 words). While efficient, it could benefit from a bit more detail, but it is not overly verbose. It gets a high score for conciseness.

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 lack of annotations and output schema, the description is too minimal for a search tool. It does not explain return format, result count, or any filtering behavior. The list of siblings suggests more comprehensive tools exist, making this one seem incomplete.

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 the description adds no extra meaning beyond the schema parameter description. Baseline score of 3 is appropriate as the schema already documents the parameter semantics adequately.

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?

Description clearly states the tool searches for tarot cards by keyword, which distinguishes it from siblings like daily_card (specific card), draw_cards (random), and get_card_meaning (specific meaning). The verb 'search' and resource 'tarot cards' are explicit and unique.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. For example, if the agent has a specific card name, get_card_meaning or list_all_cards might be more appropriate. The description does not provide any context for selection.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

9 tool updatesJan 13, 2026
- First observeddaily_card
- First observeddraw_cards
- First observedget_card_meaning
- First observedget_spread_info
- First observedinterpret_reading
- First observedlist_all_cards
- First observedlist_spreads
- First observedperform_reading
- First observedsearch_cards

Install Server

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

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: daily card, drawing multiple cards, getting card meaning, spread info, interpreting reading, listing cards/spreads, performing spread, searching. No overlap or ambiguity.

Naming Consistency4/5

Most tools follow a verb_noun pattern (draw_cards, get_card_meaning, etc.), but 'daily_card' breaks the pattern as a noun phrase. Still, the naming is mostly consistent and readable.

Tool Count5/5

9 tools is well-scoped for a tarot reading server. Each tool serves a necessary function without being too many or too few.

Completeness4/5

Core tarot functionalities are covered: listing, searching, drawing, interpreting, and performing spreads. Missing custom spread creation or user history, but the surface is sufficient for typical use.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

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

Tarot MCP Server by RoxyAPI A
com.roxyapi
Tarot card meanings, spreads and seeded reproducible readings for AI agents, one API key.
Entertainment & Media
102
Familiar Tarot
com.familiartarot
Free tarot for Claude & your AI — many decks, real card art, a true shuffle, drawn & discussed.
Entertainment & Media Games & Gamification
2
tarot A
io.github.pipeworx-io
Tarot MCP — wraps tarotapi.dev (free, no auth)
Entertainment & Media
352
Enigmata Flow MCP
io.github.enigm-io-sys
Аccess to personalized Enigmata astrological forecasts (day/week/month/thematic) for AI assistants
Entertainment & Media
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
Search Knowledge & Memory
fzlzjerry
A
license
A
quality
B
maintenance
Provides professional-grade Rider-Waite tarot readings and 11 specialized spreads through a comprehensive interpretation engine featuring elemental and context-aware analysis. It enables users to perform cryptographically secure card draws, create custom spreads, and explore detailed card symbolism via MCP or HTTP protocols.
Updated 10 days ago (2026-08-26 15:18 UTC)
14
26
15
MIT
arcana
Art & Culture Entertainment & Media
kellymears
A
license
Not graded
quality
D
maintenance
Provides tarot reading capabilities including drawing spreads, looking up card interpretations, listing cards, and retrieving reading history for LLM integration.
Updated 5 months ago (2026-03-31 17:19 UTC)
16
ISC
Familiar Tarot MCP Server
Games & Gamification
jensonChow
F
license
Not graded
quality
C
maintenance
Provides free tarot card readings for AI assistants with real deck shuffles, multiple decks, and spreads, enabling reflective practice rather than fortune-telling.
Updated 2 months ago (2026-06-26 15:13 UTC)
-

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/abdul-hamid-achik/tarot-mcp'

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

Tarot MCP Server

Features

Installation

From npm

From source

Configuration

Claude Desktop

Cursor

VSCode with Continue Extension

Other MCP-Compatible Tools

Available Tools

1. draw_cards

2. perform_reading

3. interpret_reading

4. get_card_meaning

5. list_spreads

6. get_spread_info

7. daily_card

8. search_cards

9. list_all_cards

Available Spreads

Example Usage

In Claude Desktop

In Cursor

In VSCode with Continue

Programmatic Usage

Development

Building

Testing locally

Project Structure

Troubleshooting

Common Issues

Getting Help

Contributing

Ideas for Contribution

License

Author

Acknowledgments

Resources

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `draw_cards`

2. `perform_reading`

3. `interpret_reading`

4. `get_card_meaning`

5. `list_spreads`

6. `get_spread_info`

7. `daily_card`

8. `search_cards`

9. `list_all_cards`