Skip to main content
Glama
astroway

astroway-mcp

Official
by astroway

Head Line

astroway_palmistry_head_line
Read-onlyIdempotent

Analyzes the palm's head line to reveal intellect and mental approach for palmistry readings.

Instructions

Intellect, mental approach.

[Group: Palmistry (Cheiro)] [Endpoint: POST /v1/palmistry/head-line] [Cost: 10 credits (Tier 1)]

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
lineNo
sourceNo
disclaimerNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

C2.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new operational context — the endpoint path and a 10-credit Tier 1 cost — which is useful for budgeting, but says nothing about what the reading contains or its length/format.

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?

Very short and front-loaded — the meaning phrase comes first, followed by bracketed metadata. Nothing is padded, though the brevity here is under-specification rather than disciplined economy.

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 described, and with zero parameters and full annotation coverage the calling mechanics are unambiguous. What is missing is any indication of what distinguishes this line's reading from its four palmistry siblings, which an agent needs in a toolset this large.

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 clarify; the baseline of 4 applies. The endpoint metadata (POST with an empty body) is consistent with that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Intellect, mental approach" states what the head line signifies in palmistry, but never says what the tool does — it does not state that it returns a Cheiro-style head-line reading, nor distinguish it behaviorally from sibling lines like heart_line or life_line. It effectively restates the name with a gloss, which is close to tautology.

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?

No when-to-use, when-not-to-use, or alternative named. An agent cannot tell from the description whether this is the right palmistry line to call versus fate_line, heart_line, life_line, or marriage_line, all of which appear structurally identical.

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