Skip to main content
Glama
astroway

astroway-mcp

Official
by astroway

Dream Symbol Dictionary

astroway_esoteric_dreams
Read-onlyIdempotent

Look up dream symbols and interpret their common, shadow, and recurring-dream meanings by category, element, and archetype.

Instructions

Full dream symbol dictionary with category, element, archetype, common and shadow meanings, and recurring-dream readings.

[Group: Esoteric] [Endpoint: GET /v1/esoteric/dreams] [Cost: 5 credits (Tier ½)]

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
countNo
itemsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds value annotations do not: the exact fields returned, and the cost (5 credits, Tier ½), which lets an agent reason about budget before calling.

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?

A single front-loaded sentence that names the resource first and enumerates contents second, with no wasted words. The endpoint and cost metadata are compact and separate from the prose.

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?

An output schema exists, so return values need not be spelled out, and with zero params the calling contract is trivial. However, the description omits whether this returns the entire dictionary (potentially large) or a bounded listing, and it leaves the sibling-routing gap unaddressed.

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?

The tool takes zero parameters, so there is nothing for the description to document and the baseline is 4. The endpoint and method metadata supplied alongside the description round out the calling contract.

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?

States the resource (a dream symbol dictionary) and enumerates the data it carries (category, element, archetype, common/shadow meanings, recurring-dream readings). It is clear what the tool returns, but it never distinguishes itself from close siblings like astroway_esoteric_dreams_decode or astroway_esoteric_dreams_symbol_keyword, which an agent could easily confuse it with.

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?

There is no when-to-use or when-not-to-use guidance at all. With four sibling dream tools (decode, symbol_keyword, by_element, recurring_themes) in the same group, the description gives the agent no rule for choosing this full-dictionary endpoint over a targeted lookup.

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

Deploy Server

Other Tools