Asterwise

Divisional Chart

asterwise_get_divisional_chart

Read-onlyIdempotent

Computes divisional (varga) charts from BirthData; pass chart_type for one varga, or omit chart_type for all sixteen. Each planet in each varga comes with its dignity there and whether it is vargottama; with a known birth time, each chart also has its own lagna, every planet's whole-sign house from that lagna, and a houses table.

WORKFLOW: BEFORE: RECOMMENDED — asterwise_get_natal_chart — anchor D1 before reading higher vargas. AFTER: None.

INPUT CONTRACT: chart_type enum is enforced locally. BirthData follows the global contract. Unknown birth time: omit time; lagna, houses and the houses table are then left out (birth_time_provided=false).

DO NOT CONFUSE WITH: asterwise_get_natal_chart — radix chart with houses and drishti, not the varga set. asterwise_get_chart_strength — varga-based strength scores, not placements.

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

Input Schema

TableJSON Schema

Name	Required	Description	Default
`birth`	Yes	Birth data for a single person.
`chart_type`	No	Divisional chart to return, D1 to D60. Omit to return all 16 charts.
`response_format`	No	Output format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload.	markdown

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 5, 2026

addedInput schema / properties / chart_type / description

Added value: +"Divisional chart to return, D1 to D60. Omit to return all 16 charts."

addedInput schema / properties / response_format / description

Added value: +"Output format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload."

Changed8 schema fields changedSep 4, 2026

changedInput schema / properties / birth / properties / date / description

Previous value: -"Birth date in YYYY-MM-DD format. Example: '1985-11-12'"New value: +"Birth date YYYY-MM-DD."

changedInput schema / properties / birth / properties / lat / description

Previous value: -"Birth latitude in decimal degrees. North positive, south negative. Example: 19.0760 for Mumbai, -33.8688 for Sydney"New value: +"Latitude in decimal degrees, north positive (Mumbai 19.076)."

changedInput schema / properties / birth / properties / lon / description

Previous value: -"Birth longitude in decimal degrees. East positive, west negative. Example: 72.8777 for Mumbai, -74.0060 for New York"New value: +"Longitude in decimal degrees, east positive (Mumbai 72.8777)."

changedInput schema / properties / birth / properties / person_name / description

Previous value: -"Name of the person for this chart. Example: 'Arjun Mehta'"New value: +"Person's name, used in labels only."

changedInput schema / properties / birth / properties / time / description

Previous value: -"Birth time in HH:MM 24-hour format. Example: '06:45'. Omit entirely if the birth time is unknown: a sunrise chart is used and birth_time_provided returns false. Do not pass '00:00' for an unknown time, it is treated as a real midnight birth and returns a confidently wrong ascendant."New value: +"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."

changedInput schema / properties / birth / properties / timezone / description

Previous value: -"IANA timezone for the birth location. Examples: 'Asia/Kolkata' (India), 'America/New_York' (New York), 'Europe/London' (London), 'Asia/Tokyo' (Japan), 'America/Los_Angeles' (Los Angeles), 'Europe/Paris' (Paris), 'Asia/Dubai' (Dubai), 'Asia/Singapore' (Singapore), 'America/Chicago' (Chicago), 'Australia/Sydney' (Sydney). Default: Asia/Kolkata"New value: +"IANA timezone of the birth place, e.g. 'Asia/Kolkata', 'America/New_York', 'Europe/London'. Default: Asia/Kolkata"

addedInput schema / properties / response_format / default
```
Added value: +"markdown"
```

changedInput schema / required

Previous value: -[
-  "birth",
-  "response_format"
-]New value: +[
+  "birth"
+]

Changed6 schema fields changedJul 25, 2026

addedInput schema / properties / birth / properties / time / anyOf

Added value: +[
+  {
+    "pattern": "^\\d{2}:\\d{2}$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

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

changedInput schema / properties / birth / properties / time / description

Previous value: -"Birth time in HH:MM format (24-hour). Example: '06:45'. Use '00:00' if unknown."New value: +"Birth time in HH:MM 24-hour format. Example: '06:45'. Omit entirely if the birth time is unknown: a sunrise chart is used and birth_time_provided returns false. Do not pass '00:00' for an unknown time, it is treated as a real midnight birth and returns a confidently wrong ascendant."

removedInput schema / properties / birth / properties / time / pattern
```
Removed value: -"^\\d{2}:\\d{2}$"
```
removedInput schema / properties / birth / properties / time / type
```
Removed value: -"string"
```

changedInput schema / properties / birth / required

Previous value: -[
-  "date",
-  "time",
-  "lat",
-  "lon"
-]New value: +[
+  "date",
+  "lat",
+  "lon"
+]

Changed5 schema fields changedMay 3, 2026

addedInput schema / properties / chart_type / anyOf

Added value: +[
+  {
+    "enum": [
+      "D1",
+      "D2",
+      "D3",
+      "D4",
+      "D7",
+      "D9",
+      "D10",
+      "D12",
+      "D16",
+      "D20",
+      "D24",
+      "D27",
+      "D30",
+      "D40",
+      "D45",
+      "D60"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

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

removedInput schema / properties / chart_type / enum

Removed value: -[
-  "D1",
-  "D2",
-  "D3",
-  "D4",
-  "D7",
-  "D9",
-  "D10",
-  "D12",
-  "D16",
-  "D20",
-  "D24",
-  "D27",
-  "D30",
-  "D40",
-  "D45",
-  "D60"
-]

removedInput schema / properties / chart_type / type
```
Removed value: -"string"
```

changedInput schema / required

Previous value: -[
-  "birth",
-  "chart_type",
-  "response_format"
-]New value: +[
+  "birth",
+  "response_format"
+]

First observedApr 22, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds real behavioral context beyond that: enum enforcement is local, and with an unknown birth time the lagna, houses, and houses table are omitted with birth_time_provided=false. It does not cover failure modes or rate limits, which is delegated to the docs URL.

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?

Front-loaded core sentence, then clearly labeled WORKFLOW / INPUT CONTRACT / DO NOT CONFUSE WITH blocks. Every sentence carries information; no filler.

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?

For a read-only computation tool with a full output schema, the description covers what is computed, the optional-parameter behavior, output contents, degradation without birth time, prerequisites, and sibling disambiguation. Nothing an agent needs to invoke it correctly is missing.

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 birth fields, ayanamsa, timezone, and the omission-for-unknown-time semantics are already documented in the schema. The description's 'omit chart_type for all sixteen' and the birth_time_provided note largely restate what the schema says, 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 and resource ('Computes divisional (varga) charts from BirthData') and immediately names the two siblings it is not: get_natal_chart and get_chart_strength. An agent can distinguish it from all ~90 siblings without opening a schema.

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?

Explicit WORKFLOW block recommends asterwise_get_natal_chart as the D1 anchor beforehand, states AFTER: None, and the DO NOT CONFUSE WITH section routes on the specific conditions (radix chart with houses/drishti vs. varga set; varga-based strength scores vs. placements).

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

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?