Skip to main content
Glama

Varshaphal Saham

asterwise_get_varshaphal_saham
Read-onlyIdempotent

Computes all 10 Tajika Saham (sensitive points) for a Varshaphal solar return chart. Sahams are the Tajika equivalent of Arabic Parts — mathematically derived zodiac points that focus the annual horoscope on specific life themes.

WORKFLOW: BEFORE: RECOMMENDED — asterwise_get_varshaphal — understand the base solar return chart (Varsha Pati, Muntha, Varsha Ascendant) before interpreting Saham lords. The Saham is meaningless without knowing which house it occupies from the Varsha Ascendant. AFTER: asterwise_get_varshaphal_harsha_bala — assess the Saham lord's positional happiness score to determine ease or difficulty of manifestation.

INPUT CONTRACT: Same as asterwise_get_varshaphal — BirthData plus year. year (required int): The Gregorian calendar year of the solar return, sent upstream as target_year. Not age — the civil year (e.g. 2026). Feeding age instead of year silently produces the wrong return. time (required): Solar return Ascendant is time-sensitive. Accurate birth time is required for reliable Saham interpretation.

DO NOT CONFUSE WITH: asterwise_get_varshaphal — returns the full base solar return chart including Muntha, Varsha Pati, and planet positions; Saham points are not included there. asterwise_get_varshaphal_harsha_bala — scores planet positional happiness; this tool computes zodiac points, not planet positions. asterwise_get_gemstone_recommendations — birthchart gemstone recommendations, unrelated to Tajika Saham.

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

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "birth": "<birth>",
      "year": "<year>"
    },
    "name": "asterwise_get_varshaphal_saham"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearYesVarshaphal year, four digits, e.g. 2026: the solar return nearest the birthday in that year (in UTC it can fall a day either side, or on 31 Dec for a 1 Jan birthday). Must not be before the birth year.
birthYesBirth data for tools that need the exact birth time (no sunrise fallback).
response_formatNoOutput format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload.markdown

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / year / description
      Previous value: -"Four-digit calendar year, e.g. 2026."New value: +"Varshaphal year, four digits, e.g. 2026: the solar return nearest the birthday in that year (in UTC it can fall a day either side, or on 31 Dec for a 1 Jan birthday). Must not be before the birth year."
  2. Changed1 schema field changed
    • changedInput schema / properties / birth / description
      Previous value: -"Birth data for tools that need the exact birth time.\n\nTheir API endpoints have no sunrise fallback and reject a request without\na time, so the time is required here instead of failing upstream."New value: +"Birth data for tools that need the exact birth time (no sunrise fallback)."
  3. Changed7 schema fields changed
    • changedInput schema / properties / birth / description
      Previous value: -"Birth data for a single person."New value: +"Birth data for tools that need the exact birth time.\n\nTheir API endpoints have no sunrise fallback and reject a request without\na time, so the time is required here instead of failing upstream."
    • removedInput schema / properties / birth / properties / time / anyOf
      Removed value: -[
      -  {
      -    "pattern": "^\\d{2}:\\d{2}$",
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / birth / properties / time / default
      Removed value: -null
    • changedInput schema / properties / birth / properties / time / description
      Previous 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."New value: +"Birth time HH:MM (24h), e.g. '06:45'. Required: this tool has no sunrise fallback. If the user doesn't know it, say so rather than guessing; never pass '00:00' for unknown."
    • addedInput schema / properties / birth / properties / time / pattern
      Added value: +"^\\d{2}:\\d{2}$"
    • addedInput schema / properties / birth / properties / time / type
      Added value: +"string"
    • changedInput schema / properties / birth / required
      Previous value: -[
      -  "date",
      -  "lat",
      -  "lon"
      -]New value: +[
      +  "date",
      +  "time",
      +  "lat",
      +  "lon"
      +]
  4. Changed1 schema field changed
    • changedInput schema / properties / year / description
      Previous value: -"Four-digit calendar year, e.g. 2026. Defaults to the current year when omitted."New value: +"Four-digit calendar year, e.g. 2026."
  5. Changed2 schema fields changed
    • addedInput schema / properties / response_format / description
      Added value: +"Output format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload."
    • addedInput schema / properties / year / description
      Added value: +"Four-digit calendar year, e.g. 2026. Defaults to the current year when omitted."
  6. Changed8 schema fields changed
    • 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",
      -  "year",
      -  "response_format"
      -]New value: +[
      +  "birth",
      +  "year"
      +]
  7. Changed6 schema fields changed
    • 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"
      +]
  8. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/non-destructive/idempotent, so safety is covered. The description adds meaningful behavioral context: time-sensitivity of the solar return ascendant and the silent-wrong-return failure mode when age is passed instead of year. Return-format details are partly delegated to the docs link and output schema.

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?

Well-structured with clear labeled sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE) and front-loaded purpose. Slightly long and a docs URL for the output contract adds bulk, but nothing is egregiously wasteful.

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?

Given the tool's complexity (nested birth data, time-sensitive annual chart, domain-specific Sahams) and the presence of an output schema, the description covers initiation, prerequisites, sibling differentiation, and known pitfalls. Everything an agent needs to call it correctly is present.

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 already 100%, so baseline is 3; the description goes further by restating the year contract (civil Gregorian year, not age) and the time requirement in the INPUT CONTRACT, reinforcing the most error-prone parameters. It does add value beyond the schema for the year/time semantics.

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 all 10 Tajika Saham for a Varshaphal solar return chart. Adds an analytic gloss (Tajika equivalent of Arabic Parts) that clarifies the niche resource. Explicitly distinguishes the cluster of Varshaphal-related tools in the DO NOT CONFUSE section.

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?

Provides an explicit workflow with BEFORE (get_varshaphal, with rationale) and AFTER (harsha_bala) steps, plus named alternatives with what they don't contain. This is textbook when-to-use and alternative routing.

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