Sahadeva

Analyze natal, Dasha and transit activation together

analyze_transit_activation

Read-onlyIdempotent

TIMING FOR A TOPIC. Combines the natal promise for one topic (career, marriage, wealth, education, children, property, spirituality) with the running dasha and slow transits between startIso and endIso. Use for 'when' questions about one area of life. For a plain list of current transits use analyze_transits.

Input Schema

Name	Required	Description
`date`	Yes	Birth date YYYY-MM-DD (1800–2050)
`name`	No	Person's name or a label
`time`	Yes	Local birth time HH:MM (24-hour); 6:30 PM is also accepted
`place`	No	Catalogue query or display label when explicit coordinates are supplied
`topic`	Yes
`endIso`	Yes
`asOfIso`	Yes
`latitude`	No
`startIso`	Yes
`timezone`	No	Required IANA timezone when explicit coordinates are supplied, for example Asia/Kolkata
`longitude`	No
`timezoneOffset`	No	Optional fallback offset; derived from timezone and the requested local date when omitted

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 18, 2026
- addedInput schema / properties / date / description
```
Added value: +"Birth date YYYY-MM-DD (1800–2050)"
```
- addedInput schema / properties / date / pattern
```
Added value: +"^\\d{4}-\\d{2}-\\d{2}$"
```
- addedInput schema / properties / name / description
```
Added value: +"Person's name or a label"
```
- addedInput schema / properties / time / description
```
Added value: +"Local birth time HH:MM (24-hour); 6:30 PM is also accepted"
```

Changed1 schema field changedOct 15, 2026

changedInput schema / required

Previous value: -[
-  "name",
-  "date",
-  "time",
-  "topic",
-  "asOfIso",
-  "startIso",
-  "endIso"
-]New value: +[
+  "date",
+  "time",
+  "topic",
+  "asOfIso",
+  "startIso",
+  "endIso"
+]

First observedOct 1, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety behavior is covered elsewhere. The description adds that it combines natal promise with running dasha and slow transits between startIso and endIso, which is useful computation context, but it does not disclose output format, performance, or other behavioral caveats beyond what annotations provide.

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?

The description is front-loaded with a clear purpose label ('TIMING FOR A TOPIC') followed by two tightly scoped sentences. Every sentence adds routing or scope information, with no redundant explanation of values already covered by the schema.

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?

An output schema exists, so the description need not explain return values, and it successfully covers purpose, usage, and the key alternative sibling. Given the tool's complexity and 12 parameters, it could say more about parameter roles, but the core guidance needed to select and invoke the tool is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50%, and the description only mentions startIso and endIso as a range while repeating the topic enum values already present in the schema. It offers no clarification for other required or optional parameters such as asOfIso, date, time, place versus coordinates, or timezone handling, so it fails to compensate for the missing schema descriptions.

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 function: combining natal promise for one topic with running dasha and slow transits over a time range. The scope is concrete and the sibling it is not (analyze_transits) is named, so an agent can distinguish it from related timing tools without opening another schema.

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?

Explicitly says to use it for 'when' questions about one area of life and names analyze_transits as the alternative for a plain list of current transits. It does not address other similar siblings like find_marriage_windows or fuse_timing, so it stops short of full when-not coverage, but the primary routing guidance is clear.

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

All Sahadeva 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.