Asterwise

Transits

asterwise_get_transits

Read-onlyIdempotent

Lists sign ingresses and retrograde/direct stations for all planets between two dates and returns chronological astronomical events. No birth data is needed.

WORKFLOW: BEFORE: None — no birth data or natal chart is needed. AFTER: asterwise_get_gochar — optional snapshot of transits against a natal chart.

INPUT CONTRACT: from_date and to_date are strings in the format expected by the upstream API (typically YYYY-MM-DD). Range cap (3 years, 1095 days), date order, and validity are enforced upstream, not locally. birth is not needed; older clients may still send it, and its ayanamsa is used only when ayanamsa is not given. ayanamsa picks the zodiac: 'lahiri' (default), 'raman', 'kp' are sidereal; 'tropical' gives Western sign changes (Sun into Aries at the March equinox, Moon sign changes every ~2.5 days). Station moments do not depend on it, only their longitude.

DO NOT CONFUSE WITH: asterwise_get_gochar — single-day transit snapshot with houses from Moon/Lagna, not ingress/station lists. asterwise_get_dasha_transits — dasha lord vs transit scoring for today only.

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

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": {
      "from_date": "<from_date>",
      "to_date": "<to_date>"
    },
    "name": "asterwise_get_transits"
  }
}

Input Schema

Name	Required	Description	Default
`birth`	No	Not needed. Accepted so older clients keep working; only its ayanamsa is read, when ayanamsa is not given.
`to_date`	Yes	End of the window to list ingress and station events, YYYY-MM-DD.
`ayanamsa`	No	Zodiac: lahiri (default), raman or kp sidereal; tropical for Western sign changes.
`from_date`	Yes	Start of the window to list ingress and station events, YYYY-MM-DD.
`response_format`	No	Output format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload.	markdown

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedOct 26, 2026

addedInput schema / properties / ayanamsa

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "lahiri",
+        "raman",
+        "kp",
+        "tropical"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Zodiac: lahiri (default), raman or kp sidereal; tropical for Western sign changes."
+}

removedInput schema / properties / birth / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / birth / anyOf

Added value: +[
+  {
+    "additionalProperties": false,
+    "description": "Birth data for a single person.",
+    "properties": {
+      "ayanamsa": {
+        "default": "lahiri",
+        "description": "Ayanamsa system for sidereal calculations. 'lahiri' (default, recommended for Vedic), 'kp' (Krishnamurti Paddhati), 'raman', 'tropical' (Western)",
+        "enum": [
+          "lahiri",
+          "kp",
+          "raman",
+          "tropical"
+        ],
+        "type": "string"
+      },
+      "date": {
+        "description": "Birth date YYYY-MM-DD.",
+        "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+        "type": "string"
+      },
+      "lat": {
+        "description": "Latitude in decimal degrees, north positive (Mumbai 19.076).",
+        "maximum": 90,
+        "minimum": -90,
+        "type": "number"
+      },
+      "lon": {
+        "description": "Longitude in decimal degrees, east positive (Mumbai 72.8777).",
+        "maximum": 180,
+        "minimum": -180,
+        "type": "number"
+      },
+      "person_name": {
+        "default": "Chart",
+        "description": "Person's name, used in labels only.",
+        "type": "string"
+      },
+      "time": {
+        "anyOf": [
+          {
+            "pattern": "^\\d{2}:\\d{2}$",
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Birth time HH:MM (24h), e.g. '06:45'. Omit if unknown (a sunrise chart is used and birth_time_provided=false); never pass '00:00' for unknown."
+      },
+      "timezone": {
+        "default": "Asia/Kolkata",
+        "description": "IANA timezone of the birth place, e.g. 'Asia/Kolkata', 'America/New_York', 'Europe/London'. Default: Asia/Kolkata",
+        "type": "string"
+      }
+    },
+    "required": [
+      "date",
+      "lat",
+      "lon"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / birth / default
```
Added value: +null
```

changedInput schema / properties / birth / description

Previous value: -"Birth data for a single person."New value: +"Not needed. Accepted so older clients keep working; only its ayanamsa is read, when ayanamsa is not given."

removedInput schema / properties / birth / properties

Removed value: -{
-  "ayanamsa": {
-    "default": "lahiri",
-    "description": "Ayanamsa system for sidereal calculations. 'lahiri' (default, recommended for Vedic), 'kp' (Krishnamurti Paddhati), 'raman', 'tropical' (Western)",
-    "enum": [
-      "lahiri",
-      "kp",
-      "raman",
-      "tropical"
-    ],
-    "type": "string"
-  },
-  "date": {
-    "description": "Birth date YYYY-MM-DD.",
-    "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
-    "type": "string"
-  },
-  "lat": {
-    "description": "Latitude in decimal degrees, north positive (Mumbai 19.076).",
-    "maximum": 90,
-    "minimum": -90,
-    "type": "number"
-  },
-  "lon": {
-    "description": "Longitude in decimal degrees, east positive (Mumbai 72.8777).",
-    "maximum": 180,
-    "minimum": -180,
-    "type": "number"
-  },
-  "person_name": {
-    "default": "Chart",
-    "description": "Person's name, used in labels only.",
-    "type": "string"
-  },
-  "time": {
-    "anyOf": [
-      {
-        "pattern": "^\\d{2}:\\d{2}$",
-        "type": "string"
-      },
-      {
-        "type": "null"
-      }
-    ],
-    "default": null,
-    "description": "Birth time HH:MM (24h), e.g. '06:45'. Omit if unknown (a sunrise chart is used and birth_time_provided=false); never pass '00:00' for unknown."
-  },
-  "timezone": {
-    "default": "Asia/Kolkata",
-    "description": "IANA timezone of the birth place, e.g. 'Asia/Kolkata', 'America/New_York', 'Europe/London'. Default: Asia/Kolkata",
-    "type": "string"
-  }
-}

removedInput schema / properties / birth / required

Removed value: -[
-  "date",
-  "lat",
-  "lon"
-]

removedInput schema / properties / birth / type
```
Removed value: -"object"
```

changedInput schema / required

Previous value: -[
-  "birth",
-  "from_date",
-  "to_date"
-]New value: +[
+  "from_date",
+  "to_date"
+]

First observedSep 7, 2026

TDQS

A4.8/5.0

Behavior5/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 non-obvious operational context beyond them: the 3-year/1095-day cap, date ordering and validity being enforced upstream rather than locally, and that station moments are ayanamsa-independent while longitudes are not. It also explains the legacy 'birth' parameter's silent partial use, which is exactly the kind of behavior an agent could otherwise trip over.

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?

Front-loaded one-sentence purpose followed by labeled WORKFLOW, INPUT CONTRACT, and DO NOT CONFUSE blocks that make skimming easy. There is minor redundancy — 'no birth data is needed' appears in the opening line and again in the workflow — and the external docs link carries some weight that could have been inlined.

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?

With an output schema present, the description needn't enumerate return fields, and it still characterizes the result as chronological ingress/station events. Date-format expectations, the range cap, the ayanamsa effect, and sibling routing cover everything an agent needs before invoking it.

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 parameter list is already documented; the description nonetheless adds upstream-only constraints (range cap, date order, validity) and clarifies that birth is optional and only its ayanamsa is read, and how tropical vs sidereal changes the sign-change output. It slightly restates the schema's ayanamsa enum explanation, keeping it off a 5.

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 — lists sign ingresses and retrograde/direct stations for all planets within a date window — and specifies the output shape (chronological astronomical events). It also explicitly distinguishes the tool from asterwise_get_gochar and asterwise_get_dasha_transits, so an agent can pick it without opening sibling schemas.

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 (no birth data required; optional follow-up with get_gochar) plus a dedicated 'DO NOT CONFUSE WITH' section naming the two nearest alternatives and their differing semantics (single-day snapshot with houses; dasha-lord scoring for today). When-to-use and when-not-to-use are both covered.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.