Skip to main content
Glama
astroway

astroway-mcp

Official
by astroway

Profections

astroway_prognostics_profections
Read-onlyIdempotent

Calculate annual profections to identify the profected Ascendant, lord of the year, activated house, and monthly sub-rulers for astrological forecasting.

Instructions

Calculate annual profections: profected Ascendant, lord of the year, activated house, and monthly profection sub-rulers.

[Group: Prognostics] [Endpoint: POST /v1/profections] [Cost: 20 credits (Tier 2)]

Input Schema

NameRequiredDescriptionDefault
bodyYesNatal chart plus a target date for time-based calculations: progressions, directions, profections, returns.

Output Schema

NameRequiredDescriptionDefault
mcNo
ageNo
sunNo
moonNo
ascendantNo
signIndexNo
lordOfYearNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already establish readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful operational detail of a 20-credit Tier 2 cost and the POST endpoint, but it omits any auth, rate-limit, or failure behavior. This is adequate 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.

Conciseness4/5

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

The main sentence is front-loaded and specific, and the metadata lines are compact. The endpoint/cost/group lines are useful structured extras rather than noise, though they are not prose guidance.

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 a rich schema, an output schema, and annotations covering safety, the definition is mostly complete for invoking the tool correctly. The one meaningful gap is that it does not help the agent choose this profection calculation over the sibling profection tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, including detailed notes on the natal chart body and targetDate, so the schema carries the parameter semantics. The description adds no parameter-level detail beyond what the schema already states, which is the expected baseline when coverage is complete.

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 names a specific verb (calculate) and resource (annual profections) and lists the concrete outputs: profected Ascendant, lord of the year, activated house, and monthly sub-rulers. It does not distinguish this from sibling tools such as astroway_hellenistic_brennan_profections_detail or astroway_hellenistic_hand_perfections, so an agent cannot tell from the description alone which profection endpoint to choose.

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 explicit when-to-use guidance, no exclusions, and no named alternatives. The '[Group: Prognostics]' tag implies a forecasting context, but the description never tells the agent when this tool is preferable to the other prognostics or Hellenistic profection tools.

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