Asterwise

Western Monthly Transits

asterwise_get_western_transits_monthly

Read-onlyIdempotent

30-day transit window vs natal chart. Returns day-by-day transit snapshots plus peak aspects (active 10+ days in the window). Use start_date to set the month start; defaults to today.

WORKFLOW: BEFORE: asterwise_get_western_natal. AFTER: None.

INPUT CONTRACT: birth — WesternBirthData. house_system picks the natal houses used for natal_house on each transiting planet (default placidus). start_date (optional YYYY-MM-DD) — month start; defaults to today. snapshot_time (optional HH:MM) and snapshot_timezone (IANA) read each day's sky at that local clock time instead of 12:00 UTC.

DO NOT CONFUSE WITH: asterwise_get_western_transits_daily — 1 day. asterwise_get_western_transits_weekly — 7 days.

Full output and error contract: https://docs.asterwise.com/mcp/tools/get-western-transits-monthly/

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "birth": "<birth>"
    },
    "name": "asterwise_get_western_transits_monthly"
  }
}

Input Schema

Name	Required	Description	Default
`birth`	Yes	Birth data for Western astrology tools (tropical zodiac).
`start_date`	No	First day of the 30-day window, YYYY-MM-DD. Defaults to today (UTC).
`snapshot_time`	No	Local clock time HH:MM at which each day's sky is read. Default 12:00 UTC.
`response_format`	No	Output format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload.	markdown
`snapshot_timezone`	No	IANA timezone for snapshot_time. Defaults to the birth timezone.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 26, 2026

addedInput schema / properties / snapshot_time

Added value: +{
+  "anyOf": [
+    {
+      "pattern": "^\\d{2}:\\d{2}$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Local clock time HH:MM at which each day's sky is read. Default 12:00 UTC."
+}

addedInput schema / properties / snapshot_timezone

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "IANA timezone for snapshot_time. Defaults to the birth timezone."
+}

Changed1 schema field changedOct 10, 2026

changedInput schema / properties / start_date / description

Previous value: -"Start of the window, YYYY-MM-DD. Defaults to today when omitted."New value: +"First day of the 30-day window, YYYY-MM-DD. Defaults to today (UTC)."

Changed2 schema fields changedSep 5, 2026

addedInput schema / properties / response_format / description

Added value: +"Output format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload."

addedInput schema / properties / start_date / description

Added value: +"Start of the window, YYYY-MM-DD. Defaults to today when omitted."

Changed2 schema fields changedSep 4, 2026
- addedInput schema / properties / response_format / default
```
Added value: +"markdown"
```
- changedInput schema / required
```
Previous value: -[
-  "birth",
-  "response_format"
-]New value: +[
+  "birth"
+]
```
AddedMay 1, 2026

TDQS

A4.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 the description adds real substance on top: what the output contains (per-day snapshots plus aspects active 10+ days), how each day's sky is sampled (snapshot_time in snapshot_timezone instead of 12:00 UTC), and that house_system propagates into natal_house on transiting planets. No permissions or rate-limit notes, but for a read-only computation tool that 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.

Conciseness4/5

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

Labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE) make it scannable and the scope statement is front-loaded. Minor redundancy: the start_date default-to-today rule is stated in both the opening paragraph and the input contract.

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?

Covers the prerequisite tool, sibling disambiguation, defaults for every optional parameter with a tool-specific semantic gloss, and points to the full output/error contract, with a structured output schema already present. Nothing needed to invoke it correctly 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%, so the baseline is 3; the description earns an increment by explaining a downstream effect the schema does not — house_system determines which natal house each transiting planet is placed in, and snapshot_timezone falls back to the birth timezone. start_date/snapshot_time semantics largely restate the schema descriptions.

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?

Opens with a specific scope statement: '30-day transit window vs natal chart', and names the return contents ('day-by-day transit snapshots plus peak aspects'). The DO NOT CONFUSE section explicitly contrasts it with the daily (1 day) and weekly (7 days) siblings, so an agent can select it without opening another schema.

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 prerequisite ('BEFORE: asterwise_get_western_natal') and explicit exclusions with the exact conditions that select the alternatives (daily = 1 day, weekly = 7 days). When-to-use and when-not-to-use are both stated.

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

All Asterwise tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?