Skip to main content
Glama

Vedic Astrology and Kundli MCP Server by RoxyAPI

Declination Parallels - Planets at same or opposite declination

post_vedic_astrology_parallels
Read-only

Calculate planetary declinations and find parallels (same declination) and contraparallels (opposite declination). Parallels are considered equivalent to conjunctions in strength, contraparallels to oppositions. Returns declination for each planet and all parallel/contraparallel aspects. Declination parallels API, planetary declination calculator, contraparallel aspects.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
orbNoOrb in degrees for parallel/contraparallel detection. Defaults to 1.5°.
dateYesDate in YYYY-MM-DD format. Planetary declinations are calculated for this date to find parallel and contraparallel aspects.
timeYesTime in HH:MM:SS format (24-hour). Exact time affects declination values, especially for the fast-moving Moon.
compactNoSet true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.
latitudeYesObserver latitude in decimal degrees. Used for topocentric declination corrections.
timezoneNoTimezone offset from UTC in hours. Defaults to 5.5 (IST).
longitudeYesObserver longitude in decimal degrees. Affects local time context for declination calculations.

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds beyond that by explaining the computational purpose (calculate declinations, find parallels/contraparallels) and the nature of the output (declination per planet, all aspects). No contradictions; the keyword stuffing at the end is minor noise.

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

Conciseness3/5

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

The description is three sentences plus a trailing keyword phrase ('Declination parallels API...') that appears superfluous (likely SEO). The first two sentences are concise and informative, but the third is slightly redundant and the keywords add clutter. Could be tighter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description should clarify the return structure. It only says 'Returns declination for each planet and all parallel/contraparallel aspects' – vague. An agent lacks specifics (e.g., objects vs arrays, planet names, aspect details). Given 7 parameters and no output schema, this is a notable gap.

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 coverage is 100% with parameter descriptions. The tool description does not add new parameter meaning or constraints; it provides context for the orb usage implicitly. Baseline 3 is appropriate as the schema already documents parameters thoroughly.

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 clearly states the verb 'Calculate' and the resource 'planetary declinations and find parallels/contraparallels'. It distinguishes from siblings by focusing on declination-based aspects vs. longitudinal aspects (e.g., post_vedic_astrology_aspects). The equivalence explanation (parallels=conjunctions, contraparallels=oppositions) adds specificity.

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 description describes what the tool does but offers no guidance on when to use it versus alternative tools (e.g., post_vedic_astrology_aspects, post_vedic_astrology_planetary_positions). It implies usage for declination aspects but lacks explicit when/when-not examples or references to siblings.

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.

TDQS

A3.6/5.0
Disambiguation3/5

Many tools have overlapping concepts (multiple dasha levels, monthly variants, aspects, transit), but detailed descriptions clarify each one's distinct purpose. Still, a few pairs like planetary_positions vs birth_chart or aspects_monthly vs aspects_lunar could confuse an agent initially.

Naming Consistency5/5

All tools follow a strict get_vedic_astrology_* or post_vedic_astrology_* prefix with snake_case resource names. The pattern is predictable and uniformly applied, including the hierarchical dasha drill-downs, making it easy to infer tool families.

Tool Count1/5

With 50 tools, the server is extremely heavy. Many are monthly, interval, or sub-level variants that could be parameterized or consolidated, making the set feel bloated and difficult to navigate for an agent.

Completeness5/5

The tool set covers nearly the entire Vedic astrology domain: reference data (nakshatras, rashis, yoga glossary), core charts (birth, navamsa, divisional), dasha hierarchy, transits, compatibility, doshas, panchang, KP system, and advanced calculations like Shadbala and Ashtakavarga. No significant gaps are apparent.

Resources