Skip to main content
Glama

Find the Next Transit

next_transit
Read-only

Search the sky, past or future, for when a gate is entered or an open center activated (Pro).

The only tool that answers "when" about gates: get_transits and get_person_transits read one moment and cannot see past it, so the Rave New Year comes from here.

Two searches, exactly one per call:

  • A gate: gate, optionally line and body. Its next entry, a row per body.

  • A center: person and defines. When a planet next completes one of their hanging gates into it, and which channel.

A return — Saturn, Solar, nodal, the Uranus opposition, the Kiron return — is get_cycles, not this.

Next, every, and a sweep. Without until a row is that body's FIRST arrival and the walk runs decades. With until it is every arrival inside at most a year — "in 2026", "how often this year". A sweep of past years is the first shape: a call per gate, no body, chained from searched_until. Every date is searched in the ephemeris; none follows from an age, a calendar or an earlier row.

An empty answer means nothing arrives before searched_until, not that it never does. A body already in the gate has not arrived in it; what is true now is get_person_transits.

Times come back already in timezone, with the zone named.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "next_transit"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNoOne of the thirteen bodies — 'Sun', 'Moon', 'North Node' — to narrow either search to that body.
gateNoA gate, 1 to 64. The Rave New Year is the Sun entering gate 41.
lineNoOne of that gate's six lines, to narrow a `gate` search. Only with `gate`.
afterNoWhere the search starts: ISO 8601 local date-time ('2026-09-17T09:00') or date ('2026-09-17'), on the user's own clock — no offset, no time zone. Leave it out for now. A past date is valid and is how a historical question is answered; anything outside 1781 to 2053 is refused in words that name the range.
untilNoWhere a period ends, same clock as `after`; a bare date ('2026-12-31') covers the whole of that day. Turns the answer from each body's next arrival into every arrival in the window, with `counts` per body. At most a year after `after`. Leave it out for 'when next'.
personNoA saved person's full name exactly as saved, or 'me' for the account holder, with `defines`. Their birth time has to be exact.
definesNoThe open center to search for the sky activating, with `person`.
timezoneNoThe user's IANA time zone, e.g. 'Europe/Amsterdam' — where they are NOW, not where they were born. Every time in the answer is printed in it, and a bare `after` or `until` is read on it. Pass it whenever you know the user's local time; you usually do, and we have no other way to find out. Left out, we fall back to the time zone of their birth place, which is wrong for anyone who has moved.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / defines / description
      Previous value: -"The center to search for the sky defining, with `person`."New value: +"The open center to search for the sky activating, with `person`."
  2. Changed1 schema field changed
    • changedInput schema / properties / after / description
      Previous value: -"Where the search starts: ISO 8601 local date-time ('2026-09-17T09:00') or date ('2026-09-17'), on the user's own clock — no offset, no time zone. Leave it out for now. A past date is valid and is how a historical question is answered; anything outside 1900 to 2053 is refused in words that name the range."New value: +"Where the search starts: ISO 8601 local date-time ('2026-09-17T09:00') or date ('2026-09-17'), on the user's own clock — no offset, no time zone. Leave it out for now. A past date is valid and is how a historical question is answered; anything outside 1781 to 2053 is refused in words that name the range."
  3. Changed3 schema fields changed
    • changedInput schema / properties / body / description
      Previous value: -"One of the thirteen bodies — 'Sun', 'Saturn', 'North Node'. Required for a return; optional on the other two searches, where it narrows the answer to one body."New value: +"One of the thirteen bodies — 'Sun', 'Moon', 'North Node' — to narrow either search to that body."
    • changedInput schema / properties / person / description
      Previous value: -"A saved person's full name exactly as saved, or 'me' for the account holder. Needed for a center search and for a return; their birth time has to be exact."New value: +"A saved person's full name exactly as saved, or 'me' for the account holder, with `defines`. Their birth time has to be exact."
    • changedInput schema / properties / until / description
      Previous value: -"Where a period ends, same clock as `after`; a bare date ('2026-12-31') covers the whole of that day. Turns the answer from each body's next arrival into every arrival in the window, with `counts` per body. At most a year after `after`. Leave it out for 'when next'. Not for a return."New value: +"Where a period ends, same clock as `after`; a bare date ('2026-12-31') covers the whole of that day. Turns the answer from each body's next arrival into every arrival in the window, with `counts` per body. At most a year after `after`. Leave it out for 'when next'."
  4. Changed1 schema field changed
    • changedInput schema / properties / after / description
      Previous value: -"Where the search starts: ISO 8601 local date-time ('2026-09-17T09:00') or date ('2026-09-17'), on the user's own clock — no offset, no time zone. Leave it out for now."New value: +"Where the search starts: ISO 8601 local date-time ('2026-09-17T09:00') or date ('2026-09-17'), on the user's own clock — no offset, no time zone. Leave it out for now. A past date is valid and is how a historical question is answered; anything outside 1900 to 2053 is refused in words that name the range."
  5. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds real behavior beyond them: an empty result means nothing before `searched_until` rather than never, a body already in a gate has not arrived in it, dates are computed in the ephemeris and never inferred from an age or calendar, out-of-range dates are refused with the 1781–2053 range named, and the until window is capped at a year. These are exactly the failure modes an agent would otherwise misread.

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 with the purpose and the sibling differentiation, then structured under bolded headings for the two search modes and the next/every distinction, which is well organized for a dense eight-parameter tool. Some density is unavoidable given domain jargon (Rave New Year, hanging gates, Kiron return), but the tool is legible only to an agent already fluent in this vocabulary.

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?

Even though an output schema exists, the description still states that times come back in `timezone` with the zone named, and covers the range refusal, the empty-answer interpretation, and the sweep chaining. For an eight-parameter tool with two distinct modes, nothing an agent needs in order to call 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 schema already documents each parameter; the description still adds cross-parameter semantics the schema cannot express, notably that `until` converts the result from first-arrival to every-arrival with `counts` per body, and that a sweep chains calls via `searched_until` without `body`. It does not restate per-field formats, which is correct, but the 'chained from searched_until' reference points at an output field the description never defines.

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 — search the sky, past or future, for when a gate is entered or an open center is activated — and immediately contrasts itself with get_transits, get_person_transits, and get_cycles. An agent can tell from the first two sentences exactly what question this tool answers that no sibling can.

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?

Explicitly enumerates the two mutually exclusive search shapes ('exactly one per call'), routes cycle questions to get_cycles and present-tense questions to get_person_transits, and explains the until/no-until decision with concrete user phrasings ('in 2026', 'how often this year'). Alternatives and exclusions are named, not implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources