Skip to main content
Glama

search_transits

Read-only

Find exact transit aspects between transiting and natal planets within a date range. Provide natal positions and a Julian Day window to receive aspect type, orb, and applying/separating status.

Instructions

Search for transiting planet–natal planet aspects within a time window. Supply natal positions and a Julian Day range; receive a list of exact transit moments with aspect type, orb, and applying/separating status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodiesNoTransiting bodies to include. Defaults to all planets.
end_jdYesEnd of the search window as a Julian Day in UT1 (Universal Time) — not TT, not TDB.
aspectsNoAspect types to filter (e.g. conjunction, opposition, trine). Defaults to major aspects.
max_orbNoMaximum orb in degrees (default 1.0)
start_jdYesStart of the search window as a Julian Day in UT1 (Universal Time) — not TT, not TDB. The engine converts to TT internally for the dynamical terms; each event's exact_jd is returned on this same UT1 scale.
natal_positionsYesArray of natal planet positions to check transits against

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
end_jdYesEnd of the searched window, echoed back.
eventsYes
max_orbNoOrb the search used, in degrees.
start_jdYesStart of the searched window, echoed back.
event_countYesNumber of entries in events.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv8.0.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "end_jd": {
      +      "description": "End of the searched window, echoed back.",
      +      "type": "number"
      +    },
      +    "event_count": {
      +      "description": "Number of entries in events.",
      +      "type": "integer"
      +    },
      +    "events": {
      +      "items": {
      +        "properties": {
      +          "applying": {
      +            "description": "True when the aspect is closing at that moment.",
      +            "type": "boolean"
      +          },
      +          "aspect_type": {
      +            "description": "Aspect name.",
      +            "type": "string"
      +          },
      +          "exact_jd": {
      +            "description": "Julian Day at which the aspect is closest to exact.",
      +            "type": "number"
      +          },
      +          "exact_orb": {
      +            "description": "Orb at that moment, in degrees.",
      +            "type": "number"
      +          },
      +          "natal_body": {
      +            "description": "Natal point aspected.",
      +            "type": "string"
      +          },
      +          "transiting_body": {
      +            "description": "Transiting graha.",
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "transiting_body",
      +          "natal_body",
      +          "aspect_type",
      +          "exact_jd"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "max_orb": {
      +      "description": "Orb the search used, in degrees.",
      +      "type": "number"
      +    },
      +    "start_jd": {
      +      "description": "Start of the searched window, echoed back.",
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "start_jd",
      +    "end_jd",
      +    "event_count",
      +    "events"
      +  ],
      +  "type": "object"
      +}
  2. First observedv7.0.0

TDQS

A4.2/5.0
Behavior4/5

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

The description discloses that the tool returns exact transit moments with aspect type, orb, and applying/separating status, adding behavioral detail beyond the readOnlyHint annotation. It does not mention limitations such as search range size or whether bodies/aspects default to all/major, but those are covered in schema. No contradiction with annotations.

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 no redundant words; the subject-action-object structure is front-loaded and immediately legible. Every clause contributes either the input requirement or the expected output.

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?

Given the 6-parameter schema with 100% coverage, detailed parameter descriptions, and an output schema, the description is sufficient to orient an agent. It omits explicit alternative routing, but the time-window focus and 'search' verb are enough to select this tool among siblings.

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%, so the baseline is 3; the schema already richly documents each parameter (e.g., UT1 vs TT conversion in start_jd). The tool description itself only mentions natal positions and a Julian Day range, which maps to required params but adds no extra meaning not already in the schema.

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?

The description states a specific action ('Search for') on a well-defined resource ('transiting planet–natal planet aspects') within a bounded time window. This clearly differentiates it from siblings like compute_transit, which would calculate a single transit, and compute_gochara, which returns current positions.

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

Usage Guidelines4/5

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

The description clearly implies usage context: when an agent has natal positions and needs a list of aspect events over a Julian Day range. However, it does not explicitly state when to prefer this over alternatives like compute_transit for a single moment or search_muhurta for electional timing, so no exclusions are provided.

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