Skip to main content
Glama
astroway

astroway-mcp

Official
by astroway

Dream Symbol Lookup

astroway_esoteric_dreams_symbol_keyword
Read-onlyIdempotent

Look up a dream symbol by keyword, returning an exact match when available or partial substring matches otherwise. Use it to interpret dream imagery.

Instructions

Look up a dream symbol by keyword. Exact match if available, otherwise partial substring matches.

[Group: Esoteric] [Endpoint: GET /v1/esoteric/dreams/symbol/{keyword}] [Required: keyword] [Cost: see your plan — endpoint not in the public credit manifest]

Input Schema

NameRequiredDescriptionDefault
keywordYesDream symbol to look up.

Output Schema

NameRequiredDescriptionDefault
keywordNo
matchedNo
categoryNo
archetypeNo
commonMeaningNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive/closed-world, so the bar is lower; the description nonetheless adds real behavior beyond them: exact match first, then fallback to partial substring matches, which tells the agent how results may be broadened. The cost note ('endpoint not in the public credit manifest') is a useful warning but vague on actual pricing.

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

Conciseness4/5

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

Two tight sentences front-load the purpose and matching rule; the bracketed metadata block (group, endpoint, required, cost) is boilerplate but the cost caveat carries signal. No wasted prose.

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?

With an output schema present, return values need no explanation, and the single required parameter is fully covered. The matching fallback rule and cost caveat round it out; only explicit sibling routing is missing.

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% and the single parameter is documented, so baseline would be 3. The description adds meaning beyond the schema by explaining how the keyword is matched (exact then partial substring), which helps the agent choose specific vs generic terms.

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 gives a specific verb and resource ('Look up a dream symbol by keyword'), which distinguishes it from the broader dreams siblings such as astroway_esoteric_dreams_decode and astroway_esoteric_dreams_recurring_themes. It does not explicitly name those alternatives, so differentiation is inferable rather than stated.

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?

Use is implied by 'look up a dream symbol by keyword,' but there is no explicit statement of when to pick this over the sibling dream tools (decode, by_element, recurring_themes) and no exclusions. The matching rule hints at behavior rather than routing guidance.

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