Asterwise

Western Daily Transits

asterwise_get_western_transits_daily

Read-onlyIdempotent

Current sky positions vs natal chart for a single day. Returns all 10 planets with tropical longitudes and active aspects to natal positions using transit orbs: major 3°, sextile 2°, minor 1°. Provide start_date for a specific day; defaults to today.

WORKFLOW: BEFORE: asterwise_get_western_natal — establish natal chart first. AFTER: asterwise_get_western_transits_weekly — for week view.

INPUT CONTRACT: birth — WesternBirthData (date, time, lat, lon, timezone, house_system). house_system picks the natal houses used for natal_house (default placidus). start_date (optional YYYY-MM-DD) — defaults to today. snapshot_time (optional HH:MM) and snapshot_timezone (IANA) read each day's sky at the user's own clock time instead of 12:00 UTC; data.snapshot_utc says which instant was used.

DO NOT CONFUSE WITH: asterwise_get_western_transits_weekly — 7 days vs 1 day. asterwise_get_western_transits_monthly — 30-day window vs single day.

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

Input Schema

Name	Required	Description	Default
`birth`	Yes	Birth data for Western astrology tools (tropical zodiac).
`start_date`	No	Day to compute transits for, 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: +"Day to compute transits for, 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: the orb thresholds used (major 3°, sextile 2°, minor 1°), the default snapshot instant (12:00 UTC), and how snapshot_time/snapshot_timezone override it. It stops short of describing error or empty-result behavior, deferring that to the docs URL.

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?

Sectioned and front-loaded: the core sentence comes first, then workflow, then contract, then disambiguation. It runs somewhat long, with the DO NOT CONFUSE block partly repeating what the AFTER line already implies, but no sentence is filler.

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?

Complex nested birth object, four optional parameters, and an output schema are all handled: parameters are covered, the output contract is delegated via URL, and the dependency on a prior natal chart is called out. An agent has everything needed to call it correctly on the first attempt.

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 more by explaining interaction effects the schema cannot, e.g. that house_system selects the natal houses used for natal_house and that snapshot_timezone defaults to the birth timezone. It also documents that start_date defaults to today.

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?

States a specific verb and resource (current sky positions vs natal chart for a single day) and immediately scopes it to 10 planets with tropical longitudes and transit orbs. The explicit contrast with the weekly and monthly siblings makes it unambiguous which tool to pick.

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 BEFORE/AFTER workflow (natal chart first, weekly view next) and a DO NOT CONFUSE section naming both alternatives with the discriminating dimension (1 day vs 7 days vs 30 days). Nothing is left to inference.

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

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?