Dream symbol interpretation and dream-dictionary lookups for AI agents, one API key.
Scored across 5 tools
The tools mostly target distinct operations: browse/search symbols, fetch a symbol by ID, count symbols by letter, get random symbols, and get a seeded daily symbol. The only overlap is between random exploration and daily seeded retrieval, both returning a symbol for reflection, though the seeded reproducibility gives the daily tool a clear separate purpose.
Names follow a predictable snake_case resource hierarchy with get_dreams_symbols_* variants and one post_dreams_daily endpoint. The verb change from get to post is conventional for the daily endpoint, though it slightly breaks the otherwise uniform get_ prefix.
Five tools are well-scoped for a dream-symbol dictionary API, covering browsing, lookup, navigation, and discovery without redundant endpoints. Each tool has a clear role and the set is not bloated.
The surface covers the core lifecycle: list/search symbols, retrieve details by ID, navigate by letter counts, and discover random or daily symbols. Minor gaps exist such as no dedicated category or theme filter beyond letter/keyword, but agents can work around this through search.
Browse and search our complete dream interpretation dictionary containing 2,200+ 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 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. |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| symbols | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe read-only, non-destructive operation, so the safety burden is lifted. The description adds useful content scope (2,200+ symbols, category coverage) but says nothing about result shape, pagination behavior, or rate/usage limits beyond what the schema implies.
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?
Purpose is front-loaded in the first clause, which is good, but the middle sentence is a long keyword enumeration (animals, scenarios, people, objects, emotions, body parts, colors, numbers) that reads as SEO padding rather than agent-relevant information. It is not disastrously long, but several clauses do not earn their 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?
With an output schema present, the description need not explain return values, and annotations already carry the safety profile. The description supplies the catalogue size, content categories and both retrieval modes, leaving only minor gaps such as extra sibling differentiation for a five-parameter search 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 description coverage is 100% and every parameter (q, limit, letter, offset, compact) is already documented with types, ranges and defaults in the schema. The description only restates the letter-filter and keyword-search intent, adding no syntax or format detail beyond the structured fields — the baseline 3 applies.
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?
States a specific verb pair (browse and search) plus the resource (a 2,200+ entry dream interpretation dictionary) and its content scope. It implicitly separates itself from siblings like get_dreams_symbols_id, get_dreams_symbols_letters and get_dreams_symbols_random, but never names or contrasts them explicitly.
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 closing sentence gives operative guidance for the two parameter modes: 'Filter by starting letter for A-Z navigation or search by keyword.' That is implied usage rather than explicit routing — it never says when to prefer this tool over get_dreams_symbols_random or get_dreams_symbols_letters, nor 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.
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", "chase-dreams", "losing-teeth"). | |
| 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. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| letter | Yes | |
| meaning | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read nature is covered. The description adds no behavioral details beyond that, such as error behavior for an invalid id, rate limits, or whether the response is cached; it focuses entirely on the content of the interpretation.
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 first sentence is well-placed and informative, but the description then expands into two marketing-style sentences and a long list of dream themes (snake dreams, falling dreams, water dreams, etc.) that do not help an agent invoke the tool correctly. This is bloated and not front-loaded after the opening.
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 the low complexity (one required string id), full schema coverage, and presence of an output schema, the description does not need to explain return values or parameter syntax. It states the tool's purpose clearly, though it leaves sibling differentiation to inference.
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%, and the schema fully documents both the required 'id' parameter (kebab-case format) and the optional 'compact' parameter (columnar response shape). The description adds no additional meaning for either parameter, so the 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 first sentence states a specific verb and resource: 'Get the complete dream interpretation for a specific symbol.' This clearly distinguishes it as a single-symbol lookup rather than a list or random retrieval, though it does not explicitly name or differentiate from the 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 gives only an implied usage condition ('for a specific symbol') with no explicit when-to-use guidance, no prerequisites, and no mention of the sibling alternatives (get_dreams_symbols, get_dreams_symbols_letters, get_dreams_symbols_random, post_dreams_daily).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 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. |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| letters | Yes |
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 covered. The description adds the behavioral detail that it returns counts grouped by starting letter, but does not disclose things like whether zero-count letters are included or how the response is ordered. Given an output schema exists, this is acceptable but not rich.
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 and front-loads the core purpose in the first sentence. The illustrative phrase 'from abandonment dreams to zodiac dreams' is mildly colorful but not excessive, and the rest is informative without redundancy.
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, zero-required-parameter read-only tool with an output schema, the description provides enough context to understand the purpose and use case. It does not need to explain return values because an output schema is present, and annotations cover safety.
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 only parameter, compact, is fully documented in the input schema with a clear description of its shape and token savings. Schema description coverage is 100%, so the description does not need to repeat parameter details. It adds no additional parameter semantics, matching the baseline.
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 states a specific verb and resource: 'Get the count of dream symbols available for each letter A-Z.' It also clarifies the intended structure (alphabetical letters) and distinguishes it from siblings like get_dreams_symbols by focusing on per-letter counts for dictionary navigation.
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 a concrete use case: 'Build alphabetical dream dictionary navigation to help users browse dream interpretations by letter.' It implies when to use this tool versus the general symbol endpoints, though it does not explicitly name alternatives or say 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.
Discover random dream symbols and their interpretations for daily dream insights and exploration. Each request returns different symbols from the 2,200+ 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 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. |
| Name | Required | Description |
|---|---|---|
| symbols | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior the annotations cannot: each call returns different results (non-deterministic), drawn from a 2,200+ entry database, and can return one or many symbols. It stops short of describing pagination or response shape, but the output schema handles that.
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 purpose is front-loaded correctly, but the middle sentence pads with four promotional use cases ('dream of the day features, dream journaling prompts, meditation on subconscious themes, exploring what different dreams mean') that largely restate one another. It is serviceable but not tight.
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 zero-required-parameter read tool with an output schema, the description covers what is returned, the randomness behavior, and the dataset scale. Nothing essential to invocation is missing; only the sibling relationship is left unstated.
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%, with both 'count' and 'compact' fully documented in the schema itself, so the baseline is 3. The description only echoes 'one or multiple' interpretations and adds no syntax or format detail beyond what the schema 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 states a specific verb and resource ('Discover random dream symbols and their interpretations') and the word 'random' implicitly separates it from the lookup-style siblings like get_dreams_symbols_id and get_dreams_symbols_letters. It never names an alternative, so an agent must infer the boundary rather than being told it.
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 lists concrete use cases ('dream of the day features, dream journaling prompts, meditation'), which implies when the tool fits, but gives no explicit when-not guidance and never contrasts itself with the sibling symbol tools. Usage is suggested rather than routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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) to give each user their own symbol for the day. Without a seed every caller receives the same shared symbol of the day. | |
| 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. |
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| seed | Yes | |
| symbol | Yes | |
| dailyMessage | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and non-destructive annotations, the description discloses the key behavioral trait: seeded randomness produces the same symbol for the same seed and date, while omitting the seed yields a shared daily symbol. It also states that the response includes full psychological interpretation.
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 core action and then explains seed behavior, return content, and use cases. It is somewhat paragraph-like and includes marketing-style use-case language, but it remains appropriately sized.
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?
The tool has an output schema and annotations, and the description covers the essential behavior, seed/date usage, and return content. It is complete enough for an agent to invoke 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 the schema already documents date, seed, and compact behavior in detail. The description reinforces seed and date semantics but adds little beyond the schema and does not mention the compact parameter.
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 states a specific action and resource: receiving a single dream symbol for daily reflection. It clearly conveys the daily, reproducible-symbol purpose, though it does not explicitly contrast itself with siblings like get_dreams_symbols_random.
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 explains when to provide a seed for reproducible per-user symbols and when to omit it for shared date-based symbols. It also names suitable use cases such as dream journal apps and morning ritual apps, but it does not explicitly distinguish this tool from sibling tools.
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.
post_dreams_daily1 field changedInput schema / properties / seed / descriptionPrevious value: -"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."New value: +"Optional seed for reproducible readings. Same seed + same date = same symbol every time. Pass any unique identifier (userId, email hash, session token) to give each user their own symbol for the day. Without a seed every caller receives the same shared symbol of the day."get_dreams_symbols_id1 field changedInput schema / properties / id / descriptionPrevious value: -"Unique symbol identifier in kebab-case (e.g., \"snake\", \"being-chased\", \"teeth-falling-out\")."New value: +"Unique symbol identifier in kebab-case (e.g., \"snake\", \"chase-dreams\", \"losing-teeth\")."get_dreams_symbols2 fields changedInput schema / properties / offset / defaultAdded value: +0Input schema / properties / offset / minimumAdded value: +0get_dreams_symbols3 fields changedInput schema / properties / offset / defaultRemoved value: -0Input schema / properties / offset / minimumRemoved value: -0Input schema / properties / offset / typePrevious value: -[
- "integer",
- "null"
-]New value: +"integer"get_dreams_symbols1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "limit": {
+ "type": "number"
+ },
+ "offset": {
+ "type": "number"
+ },
+ "symbols": {
+ "items": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "letter": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "letter"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "limit",
+ "offset",
+ "symbols"
+ ],
+ "type": "object"
+}get_dreams_symbols_id1 field 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"
+}get_dreams_symbols_letters1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "letters": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "type": "object"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "letters",
+ "total"
+ ],
+ "type": "object"
+}get_dreams_symbols_random1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "symbols": {
+ "items": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "letter": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "letter",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "symbols"
+ ],
+ "type": "object"
+}post_dreams_daily1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "dailyMessage": {
+ "type": "string"
+ },
+ "date": {
+ "type": "string"
+ },
+ "seed": {
+ "type": "string"
+ },
+ "symbol": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "letter": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "letter",
+ "meaning"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "date",
+ "seed",
+ "symbol",
+ "dailyMessage"
+ ],
+ "type": "object"
+}get_dreams_symbols_random1 field changedInput schema / properties / count / typePrevious value: -"number"New value: +"integer"get_dreams_symbols2 fields changedInput schema / examplesAdded value: +[
+ {}
+]Input schema / properties / compact / descriptionPrevious 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."get_dreams_symbols_id2 fields changedInput schema / examplesAdded value: +[
+ {
+ "id": "snake"
+ }
+]Input schema / properties / compact / descriptionPrevious 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."get_dreams_symbols_letters2 fields changedInput schema / examplesAdded value: +[
+ {}
+]Input schema / properties / compact / descriptionPrevious 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."get_dreams_symbols_random2 fields changedInput schema / examplesAdded value: +[
+ {}
+]Input schema / properties / compact / descriptionPrevious 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."post_dreams_daily2 fields changedInput schema / examplesAdded value: +[
+ {}
+]Input schema / properties / compact / descriptionPrevious 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."get_dreams_symbols1 field changedInput schema / properties / offset / typePrevious value: -"integer"New value: +[
+ "integer",
+ "null"
+]get_dreams_symbols1 field changedInput schema / properties / compact / descriptionPrevious 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."get_dreams_symbols_id1 field changedInput schema / properties / compact / descriptionPrevious 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."get_dreams_symbols_letters1 field changedInput schema / properties / compact / descriptionPrevious 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."get_dreams_symbols_random1 field changedInput schema / properties / compact / descriptionPrevious 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."post_dreams_daily1 field changedInput schema / properties / compact / descriptionPrevious 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."get_dreams_symbols1 field changedInput schema / properties / compactAdded 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"
+}get_dreams_symbols_id1 field changedInput schema / properties / compactAdded 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"
+}get_dreams_symbols_letters1 field changedInput schema / properties / compactAdded 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"
+}get_dreams_symbols_random1 field changedInput schema / properties / compactAdded 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"
+}post_dreams_daily1 field changedInput schema / properties / compactAdded 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"
+}get_dreams_symbolsget_dreams_symbols_idget_dreams_symbols_lettersget_dreams_symbols_randompost_dreams_dailyTarot card meanings, spreads and seeded reproducible readings for AI agents, one API key.
A private, persistent memory and method for your dreams and ideas. Sign-in required (OAuth).
One key and one balance for 2,500+ data APIs from 90+ providers. Your AI agent pays per call.
29 DNS, SEO, SSL, security, WHOIS & mail tools for AI agents. Pay per call (x402) or card API key.
Add one secure layer between your agents and this server.
