Skip to main content
Glama

Compare family members' running periods side by side

compare_family_timing
Read-onlyIdempotent

Family view for 2–6 linked people (for example wife, husband, children, parents). For each person: current mahadasha and antardasha with dates, upcoming period changes, Sade Sati / Ashtama Shani status, and the windows when two or more members are under Saturn pressure together. Use it when a question involves the whole family. It reports dated overlaps only and never treats one chart as the cause of another person's events.

Input Schema

NameRequiredDescriptionDefault
peopleYes
asOfDateNo
languageNoen
horizonYearsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "required": [
      +    "schemaVersion",
      +    "asOfIso",
      +    "endIso",
      +    "people",
      +    "sharedSaturnPressure"
      +  ],
      +  "type": "object"
      +}
  2. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower; the description still adds real content about result shape and an interpretive constraint (never treats one chart as the cause of another's events). It omits upper-bound behavior such as the 6-person cap and the 1-5 year horizon default.

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?

Three sentences, front-loaded with scope, then component breakdown, then usage and caveat. Every sentence carries information; only the output enumeration is slightly redundant given an output schema exists.

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?

For a multi-person comparison tool with an output schema, the definition is largely complete: scope, contents and an interpretation guardrail are all present. The remaining gap is parameter-level guidance around asOfDate and horizonYears.

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 0%, so the description must carry parameter meaning. It conveys the people array's 2-6 size and the relation vocabulary (wife, husband, children, parents), but asOfDate, horizonYears and language go unmentioned despite affecting output scope and language.

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: a family view comparing running periods for 2-6 linked people, with an explicit enumeration of what is reported (mahadasha/antardasha dates, upcoming changes, Sade Sati/Ashtama Shani, shared Saturn-pressure windows). This is clearly distinguishable from single-chart siblings like calculate_dasha_system or fuse_timing.

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?

"Use it when a question involves the whole family" gives a clear triggering condition, and the closing sentence sets a boundary (dated overlaps only, no causal cross-attribution). It stops short of naming alternatives, e.g. that a single-person dasha question belongs to calculate_dasha_system.

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