Dream Interpretation MCP Server by RoxyAPI

Get dream symbol by id - Dream interpretation API

get_dreams_symbols_id

Read-only

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes	Unique symbol identifier in kebab-case (e.g., "snake", "being-chased", "teeth-falling-out").
`compact`	No	Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`name`	Yes
`letter`	Yes
`meaning`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "id": {
+      "type": "string"
+    },
+    "letter": {
+      "type": "string"
+    },
+    "meaning": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "name",
+    "letter",
+    "meaning"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedAug 17, 2026

addedInput schema / examples

Added value: +[
+  {
+    "id": "snake"
+  }
+]

changedInput schema / properties / compact / description

Previous value: -"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."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."

Changed1 schema field changedJul 22, 2026

changedInput schema / properties / compact / description

Previous value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"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."

Changed1 schema field changedJul 22, 2026

addedInput schema / properties / compact

Added value: +{
+  "default": false,
+  "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.",
+  "type": "boolean"
+}

First observedJul 8, 2026

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that results contain psychological analysis, emotional significance, and waking-life connections, which gives some context about the response content. It does not cover auth, rate limits, pagination, or other behavioral details, but with annotations present the description does enough to justify a baseline 3 and contains no contradiction.

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

Conciseness2/5

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

The first sentence is specific and front-loaded, but most of the description is padded with marketing-style content about psychological analysis and a long list of dream themes like snake dreams and falling dreams. That inventory does not help an agent select or invoke the tool correctly and should be removed or drastically shortened. The description overstays its usefulness.

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 lookup with only two parameters, 100% schema coverage, and an output schema, the description plus structured fields are sufficient for correct invocation. The main missing piece, explicit routing among sibling tools, is a usage-guidelines gap rather than a completeness gap. Nothing essential to calling the tool is absent.

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 both parameters are already well documented: id's kebab-case format and compact's columnar token-saving behavior. The description does not add any parameter meaning beyond the schema, so the baseline 3 applies. There is no gap for the description to compensate for.

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 opens with 'Get the complete dream interpretation for a specific symbol,' which names a specific verb and resource and clearly indicates lookup by id. It is distinguishable from list/random siblings by the 'specific symbol' framing, though it never explicitly names or contrasts the sibling tools. The long list of dream themes after the opening is promotional rather than scope-defining, so it slightly dilutes the clarity.

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 phrase 'for a specific symbol' plus the required id parameter implies this tool is for looking up one known symbol, and the existence of siblings like get_dreams_symbols_random suggests when it should not be used. However, the description never explicitly states when to prefer this tool over get_dreams_symbols, get_dreams_symbols_letters, or get_dreams_symbols_random, nor does it provide any exclusions or prerequisites. The usage guidance is entirely implied rather than stated.

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

All Dream Interpretation MCP Server by RoxyAPI tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?