Skip to main content
Glama

Dream Symbols

asterwise_get_dream_symbols
Read-onlyIdempotent

Returns dream symbols from the database with dual-tradition interpretation: Jungian/Western psychological analysis and traditional Vedic dream-symbol meaning. 500 symbols across 8 categories. Optionally filter by category.

WORKFLOW: BEFORE: None — standalone. AFTER: asterwise_get_dream_symbol — get full detail for a specific symbol.

INPUT CONTRACT: category (optional): One of animals, nature, people, places, objects, actions, body, abstract. Omit for all 500 symbols.

DO NOT CONFUSE WITH: asterwise_get_dream_symbol — single symbol detail by name.

Full output and error contract: https://docs.asterwise.com/mcp/tools/get-dream-symbols/

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "asterwise_get_dream_symbols"
  }
}

Input Schema

NameRequiredDescriptionDefault
categoryNoOne of the 8 categories; omit for all 500 symbols.
response_formatNoOutput format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload.markdown

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / category / anyOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "enum": [
      +      "animals",
      +      "nature",
      +      "people",
      +      "places",
      +      "objects",
      +      "actions",
      +      "body",
      +      "abstract"
      +    ],
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / category / description
      Previous value: -"Symbol category to filter by, e.g. 'animals' or 'water'. Omit for all."New value: +"One of the 8 categories; omit for all 500 symbols."
  2. Changed2 schema fields changed
    • addedInput schema / properties / category / description
      Added value: +"Symbol category to filter by, e.g. 'animals' or 'water'. Omit for all."
    • addedInput schema / properties / response_format / description
      Added value: +"Output format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload."
  3. Changed2 schema fields changed
    • addedInput schema / properties / response_format / default
      Added value: +"markdown"
    • removedInput schema / required
      Removed value: -[
      -  "response_format"
      -]
  4. Added

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, closed-world, non-destructive behavior, so the safety profile is covered. The description adds useful context: the dual-tradition nature of each symbol, the total corpus size, and the default filter behavior. It stops short of describing pagination or response shape, but with an output schema present that gap is minor.

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?

Front-loads the core purpose, then uses labeled blocks (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH, docs URL) that each earn their place. No filler sentences and nothing redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only two optional params, a full output schema, and complete annotations, the description covers everything an agent needs: purpose, corpus scope, category semantics, the alternative tool, and a docs link for the full output/error contract.

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?

Schema coverage is 100%, setting a baseline of 3, and the description adds value beyond the schema by enumerating the eight valid categories in the INPUT CONTRACT and clarifying that omission returns all 500 symbols — richer than the schema's terse 'omit for all 500 symbols.' The response_format parameter is left to the schema, which is acceptable at full coverage.

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?

States a specific verb and resource ('Returns dream symbols from the database') and defines scope precisely: 500 symbols across 8 categories with dual Jungian/Western and Vedic interpretation. It explicitly distinguishes itself from the singular asterwise_get_dream_symbol.

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

Usage Guidelines5/5

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

Provides an explicit workflow block (BEFORE: none — standalone; AFTER: asterwise_get_dream_symbol), an input contract on optional category usage, and a 'DO NOT CONFUSE WITH' clause naming the sibling and its distinct role.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources