Dream Interpretation MCP Server by RoxyAPI
Server Details
Dream symbol interpretation and dream-dictionary lookups for AI agents, one API key.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 5 of 5 tools scored. Lowest: 3/5.
Each tool serves a distinct purpose: browsing/searching symbols, getting details by ID, listing counts per letter, retrieving random symbols, and fetching a daily symbol. No overlap or ambiguity.
Tools follow a consistent 'get_dreams_symbols' pattern with suffixes like '_id', '_letters', '_random', but 'post_dreams_daily' breaks the verb prefix. The structure is clear but slightly inconsistent.
Five tools cover browsing, searching, detailed lookup, alphabetical navigation, random exploration, and a daily feature—well-scoped for a dream symbol dictionary server.
Covers core dictionary operations (search, detail, random, daily) but lacks a category-based filter or batch symbol retrieval. Minor gap, but sufficient for the stated purpose.
Available Tools
5 toolsget_dreams_symbolsList and search dream symbolsAInspect
Browse and search our complete dream interpretation dictionary containing 2,000+ dream symbols with psychological meanings. Find dream meanings for animals (snake dreams, spider dreams, dog dreams), common scenarios (falling dreams, flying dreams, being chased, drowning), people (dreams about mother, father, baby, ex), objects (car, house, water, fire), emotions (fear, anxiety, love), body parts (teeth falling out, hair, eyes), colors, numbers, and abstract concepts. Filter by starting letter for A-Z navigation or search by keyword to find what your dreams mean.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search query to match against symbol names and meanings. Case-insensitive. | |
| limit | No | Maximum items to return per page. Range: 1-50, default 20. | |
| letter | No | Filter symbols by starting letter (a-z). Case-insensitive. | |
| offset | No | Number of items to skip for pagination. Default 0. | |
| compact | No | Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {"__cols":[field names],"__rows":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses the dictionary size (2,000+ symbols) and categories (animals, scenarios, etc.) but omits operational behavior like pagination, rate limits, or empty result handling. The description adds value for content understanding but lacks behavioral depth.
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?
Description is one paragraph with clear front-loading of purpose, followed by examples. The list of examples is somewhat lengthy but serves domain context. Could be slightly more concise, but no wasted words.
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?
Given 5 parameters, no output schema, and no annotations, description covers tool purpose and scope well but does not explain return format or pagination behavior (offset/limit are in schema but not described in text). Lacks completeness for an agent to fully understand output structure.
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%, so baseline is 3. Description mentions filtering by letter and keyword but does not add meaningful detail beyond schema. The compact parameter is not referenced in description, though schema explains it well. No parameter semantics improvement.
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?
Description clearly states 'Browse and search our complete dream interpretation dictionary' with specific verb (browse/search) and resource (dream symbols). It implicitly distinguishes from siblings like get_dreams_symbols_id (by ID) and get_dreams_symbols_random (random) by focusing on general listing and keyword search.
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?
Description implies usage for browsing and searching symbols but does not explicitly advise when to use this tool versus alternatives like get_dreams_symbols_id or get_dreams_symbols_random. 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_dreams_symbols_idGet dream symbol detailsBInspect
Get the complete dream interpretation for a specific symbol. Understand what your dream means with detailed psychological analysis covering subconscious symbolism, emotional significance, and connections to your waking life. Covers all major dream themes: snake dreams (hidden fears, transformation), falling dreams (loss of control, anxiety), water dreams (emotions, cleansing), death dreams (endings, transformation), teeth falling out (self-image, communication anxiety), being chased (avoidance, confronting fears), flying dreams (freedom, ambition), and thousands more dream meanings.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Unique symbol identifier in kebab-case (e.g., "snake", "being-chased", "teeth-falling-out"). | |
| compact | No | Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {"__cols":[field names],"__rows":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must convey behavioral traits. It describes the output content extensively but fails to disclose whether the operation is read-only, required permissions, error handling (e.g., unknown symbol), or any side effects.
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 front-loaded with the main purpose but becomes verbose with an extensive list of dream themes. While informative, some sentences could be trimmed without losing clarity.
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?
With no output schema, the description should outline the return structure, but it only describes themes. Missing details on fields, error states, or authentication. Incomplete for a tool with moderate complexity.
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%, so baseline is 3. The description adds no parameter-specific information beyond the schema; it focuses on the return content. No enhancement needed.
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 complete dream interpretation for a specific symbol, with a strong verb ('Get') and resource. It distinguishes itself from sibling tools (which list or randomize symbols) by focusing on a single symbol's details.
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?
No explicit guidance on when to use this tool versus siblings (e.g., get_dreams_symbols for listing, get_dreams_symbols_random for random). The context is implied but not stated, which could lead to incorrect selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dreams_symbols_lettersGet symbol counts by letterAInspect
Get the count of dream symbols available for each letter A-Z. Build alphabetical dream dictionary navigation to help users browse dream interpretations by letter - from abandonment dreams to zodiac dreams. See how many dream meanings exist for each starting letter.
| Name | Required | Description | Default |
|---|---|---|---|
| compact | No | Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {"__cols":[field names],"__rows":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not state whether the operation is read-only, any authorization requirements, or potential side effects. The description is functional but lacks transparency about 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 three sentences, focused, and front-loaded with the core action. Every sentence adds value without redundancy. Highly efficient.
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 that returns counts per letter, the description is nearly complete. It explains the purpose and usage. However, without an output schema, it could briefly mention the expected return format. Still, it adequately informs the agent.
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 has 100% coverage with a detailed description of the 'compact' parameter. The tool description adds no additional meaning beyond the schema, meeting the baseline. No extra value is provided.
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 uses a specific verb ('Get') and clearly states what is returned: the count of dream symbols for each letter A-Z. It provides a use case (building alphabetical navigation) and implicitly distinguishes from sibling tools that handle individual symbols or random picks.
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?
It explicitly states when to use this tool ('to help users browse dream interpretations by letter'). However, it does not mention alternatives or when not to use it. The context is clear but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dreams_symbols_randomGet random dream symbolsAInspect
Discover random dream symbols and their interpretations for daily dream insights and exploration. Each request returns different symbols from the 2,000+ dream meaning database - perfect for dream of the day features, dream journaling prompts, meditation on subconscious themes, or exploring what different dreams mean. Get one or multiple random dream interpretations with full psychological meanings.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of random symbols to return (1-10). Default: 1. | |
| compact | No | Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {"__cols":[field names],"__rows":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description alone must convey behavior. It explains the tool is read-only and returns random symbols from a large database. However, it lacks details about response structure (e.g., exact fields returned) or potential side effects. The description is adequate but could be more specific about output shape.
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 covering purpose, use cases, and parameter hint. Efficient and front-loaded with key action. Minor improvement possible by separating parameter details more explicitly, but overall no wasted words.
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?
Given low complexity (2 optional params, no output schema), the description covers randomness, database size, use cases, and count flexibility. It doesn't mention error handling or empty states, but for a simple random fetch tool, it is sufficiently complete. Missing output schema shifts some burden to description, which partly addresses it.
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 detailed descriptions for both parameters (count: range, default, example; compact: explanation of token optimization). The description adds little new meaning beyond reinforcing 'one or multiple' symbols. Baseline 3 is appropriate as schema already provides sufficient semantics.
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 'Discover random dream symbols and their interpretations', specifying a unique action (returning random entries) and resource (dream symbols database). It differentiates from siblings like get_dreams_symbols (likely for specific queries) and get_dreams_symbols_id (by ID) by emphasizing randomness and daily exploration.
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 lists ideal use cases: 'dream of the day features, dream journaling prompts, meditation on subconscious themes'. It implies randomness per request ('Each request returns different symbols'), providing clear context. However, it does not explicitly state when to avoid this tool or directly compare to siblings for exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_dreams_dailyGet daily dream symbolAInspect
Receive a single dream symbol for daily reflection and subconscious exploration. Uses seeded randomness so the same seed gets the same symbol on the same day, perfect for "Dream Symbol of the Day" features. Provide a seed (userId, email hash, session token) for reproducible consistency, or omit for date-based daily symbols. Returns the symbol with full psychological interpretation. Great for dream journal apps, wellness platforms, morning ritual apps, and meditation tools.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date for the reading in YYYY-MM-DD format. Defaults to today (UTC). Useful for viewing past daily readings or pre-generating future ones. | |
| seed | No | Optional seed for reproducible readings. Same seed + same date = same symbol every time. Pass any unique identifier (userId, email hash, session token). Omit for anonymous daily readings. | |
| compact | No | Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {"__cols":[field names],"__rows":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses seeded randomness, deterministic behavior with same seed+date, return of full interpretation, and token optimization via compact parameter. No annotations exist, so description carries full burden; it omits error behavior or rate limits, but core behaviors are covered.
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 a single paragraph that front-loads the core purpose, then explains seed and compact. It is moderately concise, but some phrases like 'great for...' could be trimmed. Still, it earns its sentences.
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?
Given low complexity (3 params, no required, no enums, no output schema), the description covers the main behavioral aspects and use cases. It does not detail the return format beyond 'full psychological interpretation,' but this is sufficient for an agent to understand the tool's purpose.
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 baseline is 3. The description adds minimal extra semantics beyond schema, e.g., explaining seed purpose for reproducibility and compact for cost savings, but does not significantly augment what schema already provides.
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 it 'Receive a single dream symbol for daily reflection and subconscious exploration,' with a specific verb and resource. It distinguishes from sibling tools by emphasizing seeded randomness for daily features, which siblings like get_dreams_symbols_random or get_dreams_symbols do not specifically mention.
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?
Provides clear contexts: 'perfect for Dream Symbol of the Day features' and lists apps. It explains seed usage for reproducibility vs. omission for date-based. Does not explicitly exclude use cases or mention alternatives, but sibling names imply different symbol retrieval needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!