Skip to main content
Glama
arthiqlabs

Vedaksha

by arthiqlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Hybrid

compute_transit

Read-only

Calculate transiting planet positions at a chosen time against your natal chart. Returns both transit and natal longitudes to identify aspects between them.

Instructions

Compute transiting planet positions relative to a natal chart at a specific moment. Returns planet longitudes for the transit time alongside natal positions, enabling aspect calculation between transit and natal placements.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
natal_jdYesJulian Day of the natal chart in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms.
natal_latYesNatal geographic latitude in degrees [-90, +90]
natal_lonYesNatal geographic longitude in degrees [-180, +180], east positive
transit_jdYesJulian Day of the transit moment to compute, in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
natal_jdYesJulian Day of the natal chart, echoed back.
transit_jdYesJulian Day of the transit moment, echoed back.
natal_positionsYesNatal positions used for the comparison.
transit_positionsYesPositions at the transit moment.
transit_natal_aspectsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv8.0.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "natal_jd": {
+      "description": "Julian Day of the natal chart, echoed back.",
+      "type": "number"
+    },
+    "natal_positions": {
+      "description": "Natal positions used for the comparison.",
+      "items": {
+        "properties": {
+          "distance": {
+            "description": "Distance from the observer in AU.",
+            "type": "number"
+          },
+          "latitude": {
+            "description": "Ecliptic latitude in degrees.",
+            "type": "number"
+          },
+          "longitude": {
+            "description": "Longitude in degrees [0, 360), sidereal when an ayanamsha was applied.",
+            "type": "number"
+          },
+          "name": {
+            "description": "Body name.",
+            "type": "string"
+          },
+          "speed": {
+            "description": "Daily motion in degrees per day, negative when retrograde.",
+            "type": "number"
+          }
+        },
+        "required": [
+          "name",
+          "longitude",
+          "latitude",
+          "distance",
+          "speed"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "transit_jd": {
+      "description": "Julian Day of the transit moment, echoed back.",
+      "type": "number"
+    },
+    "transit_natal_aspects": {
+      "items": {
+        "properties": {
+          "applying": {
+            "description": "True when the aspect is closing.",
+            "type": "boolean"
+          },
+          "aspect_angle": {
+            "description": "Exact angle of the aspect in degrees.",
+            "type": "number"
+          },
+          "aspect_type": {
+            "description": "Aspect name.",
+            "type": "string"
+          },
+          "natal_body": {
+            "description": "Natal graha aspected.",
+            "type": "string"
+          },
+          "natal_body_index": {
+            "description": "Index into natal_positions.",
+            "type": "integer"
+          },
+          "orb": {
+            "description": "Departure from exact, in degrees.",
+            "type": "number"
+          },
+          "transit_body": {
+            "description": "Transiting graha.",
+            "type": "string"
+          },
+          "transit_body_index": {
+            "description": "Index into transit_positions.",
+            "type": "integer"
+          }
+        },
+        "required": [
+          "transit_body",
+          "natal_body",
+          "aspect_type",
+          "orb"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "transit_positions": {
+      "description": "Positions at the transit moment.",
+      "items": {
+        "properties": {
+          "distance": {
+            "description": "Distance from the observer in AU.",
+            "type": "number"
+          },
+          "latitude": {
+            "description": "Ecliptic latitude in degrees.",
+            "type": "number"
+          },
+          "longitude": {
+            "description": "Longitude in degrees [0, 360), sidereal when an ayanamsha was applied.",
+            "type": "number"
+          },
+          "name": {
+            "description": "Body name.",
+            "type": "string"
+          },
+          "speed": {
+            "description": "Daily motion in degrees per day, negative when retrograde.",
+            "type": "number"
+          }
+        },
+        "required": [
+          "name",
+          "longitude",
+          "latitude",
+          "distance",
+          "speed"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "natal_jd",
+    "transit_jd",
+    "natal_positions",
+    "transit_positions",
+    "transit_natal_aspects"
+  ],
+  "type": "object"
+}
  2. First observedv7.0.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already carry the safety profile (readOnlyHint=true), lowering the burden. The description adds useful framing by disclosing that the result contains both transit and natal longitudes for aspect work. It does not go deeper into edge behaviors (e.g., invalid date handling, planet set included, precision), which is acceptable but not rich given the annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two sentences with zero waste: the first commits to the computation, the second to the return shape and purpose. Front-loaded and maximally signal-dense — every sentence earns its place.

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 100% parameter coverage, a rich output schema, and read-only annotations, the description covers what is computed, relative to what, and for what purpose. The only gap is that the roles of natal_lat/natal_lon in a transit computation are left to the schema, which documents their units but not their algorithmic function. Still, an agent can select and invoke the tool correctly.

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?

Schema description coverage is 100% — all four parameters (natal_jd, natal_lat, natal_lon, transit_jd) have detailed unit/format guidance, including the UT1-vs-TT distinction. The tool description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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 ('compute') and resource ('transiting planet positions relative to a natal chart at a specific moment'), then specifies the output shape (transit longitudes alongside natal positions). The scope is unambiguous enough to distinguish it from compute_natal_chart (natal only), compute_synastry (two-person comparison), and compute_gochara, without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The use case is implied via 'enabling aspect calculation between transit and natal placements,' which gives clear context. However, it never explicitly routes the agent away from domain-overlapping siblings like compute_gochara (also transit-related) or search_transits (searching transits), so when-to-use vs alternatives 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.

Deploy Server

Other Tools