AstroWay Astrology API (full catalogue)

Prashna: number to sign

astroway_vedic_prashna_number

Read-onlyIdempotent

A querent's number read as a sign. system navamsa108 (default): 1-108 as the navamsas from 0 Aries, the sign and its navamsa. ashtamangala: the three-digit Prasna Marga number (digits 1-8) with each digit's planet and parity and the tithi, nakshatra, weekday, rasi and bhuta from its remainders. Numbers above 108 point at /vedic/kp/horary (KP 1-249).

[Group: Vedic] [Endpoint: POST /v1/vedic/prashna/number] [Required: number] [Cost: 10 credits (Tier 1)]

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": {
      "number": "<number>"
    },
    "name": "astroway_vedic_prashna_number"
  }
}

Input Schema

Name	Required	Description	Default
`fields`	No	Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response.
`number`	Yes
`system`	No	navamsa108 (default): a number 1-108 read as the navamsas of the zodiac from 0 Aries. ashtamangala: the three-digit Prasna Marga number, each digit 1-8. KP numbers 1-249 are /v1/vedic/kp/horary.	navamsa108
`precision`	No	Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn.

Output Schema

Name	Required	Description	Default
`sign`	No
`span`	No
`arudha`	No
`number`	No
`system`	No
`sources`	No
`signName`	No
`kpNumbers`	No
`navamsaSign`	No
`navamsaInSign`	No
`navamsaSignName`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is fully covered by structured data. The description's added behavior is the valid-range boundary and the out-of-range redirect, which is genuinely useful, but it says nothing about error handling or how the two systems' outputs differ in shape. Nothing here contradicts the annotations.

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?

Dense but front-loaded – the lead sentence states the operation, then each mode gets a compact clause, with the redirect last. No filler; the bracketed group/endpoint/required/cost lines are scannable metadata rather than prose bloat.

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?

With an output schema and full annotations already present, the description only needs to explain the input space and mode selection, which it does across both systems plus the out-of-range case. The remaining gap is its relationship to the other prashna tools and the failure mode for out-of-range values in navamsa108.

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?

The schema leaves `number` undocumented apart from min 1 / max 888, and the description fills that gap well: 1-108 maps to navamsas from 0 Aries, three-digit readings use 1-8 digits, and that is why the maximum reaches 888. It does not clarify how the number and `system` interact when a value like 250 is sent with navamsa108.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: it reads a querent's number as a sign, and enumerates exactly what each mode returns (sign+navamsa, or the three-digit Prasna Marga number with planets, parity, tithi, nakshatra, weekday, rasi, bhuta). The sibling differentiation is partial – it redirects out-of-range numbers to /vedic/kp/horary but says nothing about how it relates to astroway_vedic_prashna_chart or astroway_vedic_prashna_analysis.

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?

Gives a concrete routing rule (numbers above 108 belong to /vedic/kp/horary) and implicitly tells the agent which mode to select based on the number's shape (1-108 vs three-digit 1-8). It does not state when to prefer this over the other prashna siblings or what to do if a caller passes, say, 200 with navamsa108.

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

All AstroWay Astrology API (full catalogue) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?