Free Vedic astrology: panchang, kundali, transits, matching, doshas, eclipses, numerology
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.8/5 across 17 of 17 tools scored.
Each tool targets a distinct astrological calculation or domain: dosha checks, birth charts, compatibility, muhurta, panchang, numerology, transits, and Jaimini layer. Even similar tools (e.g., get_panchang vs get_muhurta_timings) are explicitly differentiated in their descriptions, and cross-references tell the agent which to use for which question.
All tools follow a consistent verb_noun pattern: 'get_' for data retrieval and 'check_' for yes/no dosha assessments. No camelCase or mixed conventions. The naming is predictable and readable.
At 17 tools, the set is slightly above the ideal 15-tool ceiling, but it is well-scoped for the breadth of Vedic astrology: each tool earns its place covering a distinct sub-domain. The count feels justified rather than bloated.
The surface covers the full lifecycle of a birth chart (details, full kundli, dasha), doshas (manglik, kaal sarp, sade sati), compatibility (kundli match), event planning (muhurta, panchang, year events, eclipses), numerology (personal, mobile, name), and advanced layers (upapada, transits). No obvious gaps or dead ends.
check_kaal_sarpKaal Sarp dosha checkAReturns a yes/no Kaal Sarp dosha verdict for ONE birth chart -- the condition where the seven classical grahas all fall on one side of the Rahu-Ketu axis -- plus which of the twelve named types it is (Anant, Kulik, Vasuki, Shankhpal and the rest), whether the hemming is full or partial, the houses involved, and a plain explanation of the finding. Use this for 'do I have kaal sarp dosh' questions. It is a different dosha from the Mars one (check_manglik) and from marriage-pair doshas (get_kundli_match); ask for each separately. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Needs an exact birth time -- partial hemming can flip with a few minutes' error.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead. | |
| latitude | No | Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too. | |
| timezone | No | IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| birth_date | Yes | Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected). | |
| birth_time | Yes | Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the computation is read-only, deterministic, uses Swiss Ephemeris and Lahiri ayanamsa, has rate limits (30 req/min/IP per instance plus shared 60/min/IP), and warns that partial hemming can flip with time errors. These details go beyond annotations (which already indicate readOnlyHint and idempotentHint), fully informing the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but contains all necessary information without redundancy. It could be slightly better structured (e.g., bullet points for rate limits), but it is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, behavior, parameter constraints, and rate limits. It lacks an explicit output schema but explains the return type. Given moderate complexity, it is quite complete, though edge cases (e.g., what happens if birth_date is invalid) are not detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all 6 parameters. The description does not add new parameter-level detail beyond reinforcing that birth_time is required and sensitive, but it does not provide additional syntax or meaning. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning a yes/no verdict for Kaal Sarp dosha, explains the condition, and lists additional output like type and houses. It distinguishes from sibling tools by mentioning check_manglik and get_kundli_match.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it ('do I have kaal sarp dosh' questions) and when not to (different doshas, marriage-pair doshas). It also notes the need for an exact birth time, providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_manglikManglik (Mangal dosha) checkAReturns a yes/no Manglik (Mangal / Mars dosha) verdict for ONE person's birth chart, with severity (none, mild, medium or high), which of the three classical reference points trigger it (Mars counted from the ascendant, from the Moon, from Venus), the classical cancellations that apply, and the traditional remedies for it. Use this for 'am I manglik / do I have mangal dosh' questions, and run it per person before a marriage discussion. It scores ONE chart -- for the two-chart compatibility score use get_kundli_match; for the Rahu-Ketu hemming dosha use check_kaal_sarp. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Remedies are the classical prescriptions, reported as data and not as advice.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead. | |
| latitude | No | Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too. | |
| timezone | No | IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| birth_date | Yes | Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected). | |
| birth_time | Yes | Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by explaining it is a read-only deterministic computation using Swiss Ephemeris and Lahiri ayanamsa, with rate limits (30 req/min/IP per instance, 60 shared), no auth required, and that remedies are data not advice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but well-structured with front-loaded verdict result. Every sentence adds value, though it could be more concise by splitting into sections. Still effective and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an astrological tool with 6 parameters and no output schema, the description fully explains the return values (verdict, severity, triggers, cancellations, remedies), usage context, and alternatives. Annotations cover all hints, and the description fills any gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 6 parameters. The description adds extra guidance on parameter usage, such as when to omit place and use lat/lon/timezone, format requirements, and geocoding behavior, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a yes/no Manglik verdict with severity, triggers, cancellations, and remedies for one person's chart. It explicitly distinguishes from siblings: 'for the two-chart compatibility score use get_kundli_match; for the Rahu-Ketu hemming dosha use check_kaal_sarp.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this for "am I manglik / do I have mangal dosh" questions, and run it per person before a marriage discussion.' It also names alternative tools for different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_birth_detailsBirth details (nakshatra, rashi, lagna, navamsa lagna)AReturns just the identity fields of a Vedic birth chart: the Moon's janma nakshatra (birth star) with its 1-27 number and pada, the janma rashi (moon sign) with its classical lord and the house it occupies, the lagna (ascendant) with degree in sign, nakshatra, pada and lord, and the navamsa (D9) lagna with its lord. Use this for the common single questions -- 'what is my nakshatra / rashi / lagna' -- and to fetch janma_nakshatra and janma_rashi values that get_muhurta_timings accepts. It returns NO planet table, no yogas and no dasha: for those call get_janam_kundali (whole chart) or get_dasha_periods (dasha only). Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa, whole-sign houses); no writes, no auth. Rate limits are counted per server instance: at least 30 requests/min/IP on this endpoint, plus a shared engine budget of at least 60/min/IP across all birth-chart tools.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead. | |
| latitude | No | Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too. | |
| timezone | No | IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| birth_date | Yes | Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected). | |
| birth_time | Yes | Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context: it is a deterministic computation using Swiss Ephemeris, Lahiri ayanamsa, whole-sign houses; no writes, no auth. Rate limits are provided: at least 30 req/min/IP on this endpoint, plus a shared engine budget of at least 60/min/IP. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear order: what it returns, use cases, exclusions, technical details, and rate limits. It is front-loaded with the most important information. However, it is somewhat verbose for a tool; minor trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by detailing output fields (nakshatra with number and pada, rashi with lord and house, lagna with degree, etc.). It also covers computational method, auth, and rate limits. The description is complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for all 6 parameters. The description does not add significant parameter-level meaning beyond what the schema provides, though it does clarify output fields. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns 'just the identity fields of a Vedic birth chart' and lists them (nakshatra, rashi, lagna, navamsa lagna). It is distinct from siblings such as get_janam_kundali and get_dasha_periods by explicitly stating what it does not return.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: 'for the common single questions -- what is my nakshatra / rashi / lagna' and to fetch values for get_muhurta_timings. It also tells when not to use it by stating it returns NO planet table, yogas, or dasha, and directs to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dasha_periodsVimshottari dasha periodsAReturns the Vimshottari dasha timetable for one birth chart: the mahadasha, antardasha and pratyantardasha running right now with their end dates, the mahadasha in force at birth with its unexpired balance in years-months-days, and the full nine-mahadasha lifetime timeline with a start and end date per period. For a chart cast at the present moment no dasha has elapsed yet, so the birth mahadasha stands in and the result is flagged is_birth_fallback -- do not report it as a separately computed current period. Use this for 'which dasha am I in', 'when does my Saturn mahadasha start' and any life-period timeline question. It returns dates only -- no interpretation of what a period brings. For the planet placements those dasha lords sit in, call get_janam_kundali. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa) from the Moon's birth nakshatra; no writes, no auth. Rate limits are counted per server instance: at least 30 requests/min/IP on this endpoint, plus a shared engine budget of at least 60/min/IP across all birth-chart tools. Dates shift with birth-time accuracy.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead. | |
| latitude | No | Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too. | |
| timezone | No | IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| birth_date | Yes | Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected). | |
| birth_time | Yes | Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing the deterministic computation method (Swiss Ephemeris, Lahiri ayanamsa from Moon's nakshatra), confirming no writes or auth, and providing specific rate limits (30 req/min/IP per endpoint, 60/min/IP shared). This fully discloses the tool's behavior and constraints, with no contradictions to 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and then elaborates efficiently. While every sentence adds value, the length is slightly high, and some phrases (e.g., 'no writes, no auth') could be integrated more tightly. Overall, it is well-structured and focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains the return data (current periods with end dates, birth mahadasha with balance, full timeline with start/end, is_birth_fallback flag). It also references the sibling tool for interpretation. This covers all needed context for an agent to understand and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema, such as noting that 'place' is preferred and geocoded, but does not significantly enhance parameter understanding. The parameter semantics are adequate but not improved beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the Vimshottari dasha timetable for one birth chart, listing specific periods (mahadasha, antardasha, pratyantardasha) and the full lifetime timeline. It explicitly distinguishes from a sibling tool (get_janam_kundali) by noting it provides only dates, not interpretations. This makes the purpose highly specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases ('which dasha am I in', 'when does my Saturn mahadasha start'), states what the tool does not do ('no interpretation'), and directly names an alternative (get_janam_kundali). It also handles an edge case (current chart with no elapsed dasha) with clear instructions. This provides comprehensive guidance for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_eclipsesSolar & lunar eclipses for a yearAReturns every solar and lunar eclipse of a calendar year with local visibility for one city: eclipse type (total, partial, annular or penumbral), date, the sparsha (first contact), madhya (maximum) and moksha (release) times, the magnitude, and a locally_visible flag. That flag is the one that matters for practice -- sutak observance applies only where the eclipse is actually visible. Use this for 'which eclipses fall in this year' and 'is it visible here' questions, and for sutak timing. For festivals and vrat dates use get_year_events; for the rest of a day's almanac use get_panchang. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa), served from a shared cache -- a cold or expired entry recomputes and can take ~30s; no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Constraints: the year must be within two years either side of the current year, and visibility is evaluated for the nearest of 50 supported cities.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Gregorian calendar year as a number, e.g. 2026. Only the current year plus or minus two is supported; anything else is rejected. | |
| place | No | City as free text, e.g. "Jaipur" or "Chennai, India". Omit to use Delhi. Any input is snapped to the nearest of 50 supported cities; visibility and contact times are reported for that city. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds: read-only deterministic computation using Swiss Ephemeris, Lahiri ayanamsa, shared cache with potential ~30s recompute, no writes, no auth, rate limits (30 req/min/IP per instance, shared engine budget 60/min/IP). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph but each sentence provides essential information. Front-loaded with purpose, then behavioral details, then constraints. No redundant or excessive text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description fully explains what is returned (list of eclipses with type, date, times, magnitude, flag). Covers complexity of parameters and behavior, making it complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description adds meaning by explaining that place is snapped to nearest of 50 cities, year must be within ±2 of current year, and the locally_visible flag's significance for sutak.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns solar and lunar eclipses for a year with local visibility for one city. It specifies eclipse types, times, magnitude, and a locally_visible flag. It distinguishes from sibling tools like get_year_events and get_panchang by stating what they are for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool: for 'which eclipses fall in this year' and 'is it visible here' and for sutak timing. Provides alternatives: get_year_events for festivals, get_panchang for daily almanac. Also documents constraints like year within ±2 years and city snapping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_janam_kundaliJanam Kundali (Vedic birth chart)AReturns a full Vedic birth-chart (janam kundali) summary for one person from their birth date, time and place: the lagna (ascendant) with sign, nakshatra, pada and lord; all nine grahas with sidereal sign, house, nakshatra, pada, dignity and retrograde/combust flags; the currently running Vimshottari mahadasha and antardasha with end dates, omitted only for a chart cast at the present moment, where no dasha has yet elapsed; and the most notable classical yogas detected, with a count of how many were found in all. Use this when the user wants their whole chart read. Prefer the cheaper, narrower sibling when the question is narrow: get_birth_details for only nakshatra / moon sign / lagna, get_dasha_periods for the full dasha timetable, get_upapada_arudha for the Jaimini layer, get_transits for where the planets are RIGHT NOW rather than at birth. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa, whole-sign houses); no writes, no auth. Rate limits are counted per server instance: at least 30 requests/min/IP on this endpoint, plus a shared engine budget of at least 60/min/IP across all birth-chart tools. Accuracy depends on birth-time precision.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead. | |
| latitude | No | Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too. | |
| timezone | No | IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| birth_date | Yes | Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected). | |
| birth_time | Yes | Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds further behavioral context: deterministic computation, no writes, no auth, rate limits, and accuracy dependence on birth-time precision. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive and well-structured, front-loading the main result. While it is lengthy, every sentence adds value, making it a minor deduction for slight verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and high complexity, the description covers purpose, usage guidelines, behavioral traits, and parameter details thoroughly, including an important note about dasha omission for present-moment charts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds valuable context beyond schema: explains the place vs. lat/lon/timezone relationship, required format for birth_date and birth_time, and why birth_time must be accurate. This significantly aids correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a full Vedic birth-chart summary, listing components like lagna, grahas, dasha, and yogas. It distinguishes itself from sibling tools by naming cheaper alternatives for narrower queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when the user wants their whole chart read' and provides clear guidance on when to use sibling tools like get_birth_details, get_dasha_periods, etc.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_kundli_matchKundli Milan (Ashtakoot compatibility)AReturns classical Ashtakoot marriage compatibility (kundli milan / gun milan) between two people from both birth charts: each of the eight koots (varna, vashya, tara, yoni, graha maitri, gana, bhakoot, nadi) with points earned out of its maximum, the total out of 36, any koot-level dosha, the classical cancellation that applies to it if one does, and an overall verdict. Use this whenever real marriage matching is asked for. get_love_compatibility is name-numerology entertainment and is NOT a substitute. Nadi/bhakoot dosha reported here is chart-pair compatibility, not the individual Mars dosha -- for that call check_manglik on each person. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Both people need an exact birth time and place.
| Name | Required | Description | Default |
|---|---|---|---|
| person_a | Yes | First person: gender plus birth date, birth time and place (or coordinates + timezone). | |
| person_b | Yes | Second person: same fields as person_a. Their birth place may differ from person_a's. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint=false), the description adds critical behavioral traits: 'Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools.' It also clarifies that Nadi/bhakoot dosha is chart-pair compatibility, not individual Mars dosha. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive, with no wasted sentences. It front-loads the core purpose and then efficiently covers usage, behavioral traits, parameter context, and return values. Each sentence provides distinct value, achieving an excellent balance of detail and brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description thoroughly explains the return structure: 'each of the eight koots... with points earned out of its maximum, the total out of 36, any koot-level dosha, the classical cancellation that applies to it if one does, and an overall verdict.' It also specifies prerequisites (exact birth time and place). This provides complete context for an agent to understand what the tool does and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter. The description adds semantic value by explaining why gender is required ('several koots are scored asymmetrically') and the necessity of exact birth time ('the ascendant moves about one degree every four minutes'). It also enriches understanding by outlining what the tool returns (eight koots, points, totals, dosha, cancellation, verdict).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Returns' and the resource 'classical Ashtakoot marriage compatibility (kundli milan / gun milan) between two people from both birth charts'. It explicitly differentiates from sibling tool 'get_love_compatibility', ensuring the agent selects the correct tool for real marriage matching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use this whenever real marriage matching is asked for.' Directly contrasts with 'get_love_compatibility' which is 'name-numerology entertainment and is NOT a substitute.' Also advises to call 'check_manglik' for individual Mars dosha, covering when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_love_compatibilityLove compatibility by name numerologyAReturns a light-hearted name-compatibility score between two people from Pythagorean numerology: each name reduces to a digit 1-9 (any master number 11/22/33 is reported alongside), the pair maps to a 0-100 score, and a short fixed reading and band come with it. Use this ONLY for entertainment, and say so when presenting it. It uses names, not birth data, so it can say nothing real about a relationship: for genuine marriage matching call get_kundli_match, which scores both birth charts on the Ashtakoot system. Read-only deterministic arithmetic over a fixed number table -- no ephemeris, no birth details, no writes, no auth, at least 30 requests/min/IP per server instance.
| Name | Required | Description | Default |
|---|---|---|---|
| name_a | Yes | First person's name in Latin letters, e.g. "Rahul". Must contain at least one A-Z letter; digits and punctuation are ignored when scoring. | |
| name_b | Yes | Second person's name in Latin letters, e.g. "Priya". Same rules as name_a. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds further details: 'Read-only deterministic arithmetic over a fixed number table -- no ephemeris, no birth details, no writes, no auth, at least 30 requests/min/IP per server instance.' This goes beyond annotations and clarifies the tool's behavior comprehensively. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with purpose. It packs useful information but could be slightly more concise. Still, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains what the return includes (score, reading, band) and mentions master numbers. It fully captures the tool's functionality and constraints given its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds context about ignoring digits and punctuation, but this is already implied in the schema. Baseline 3 is appropriate as the schema handles most semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a name-compatibility score from Pythagorean numerology, detailing the digit reduction, scoring, and output components. It distinguishes itself from sibling 'get_kundli_match' by specifying that 'get_love_compatibility' is for entertainment and not based on birth data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this ONLY for entertainment, and say so when presenting it.' and contrasts with 'get_kundli_match' for real marriage matching, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_mobile_numerologyMobile number numerologyAReturns a numerological reading of a mobile or landline number: the extracted digit string, the digit total, the single 1-9 number it reduces to, the overall vibe that reduced number carries, and the traditional meaning of each distinct digit present. Use this for 'is my phone number lucky' style questions, or when choosing between candidate numbers. It reads a number string only -- nothing about the person -- so for anything tied to a birth date use get_numerology. Read-only deterministic arithmetic over a fixed number table -- no ephemeris, no network lookup of the number, no writes, no auth, at least 30 requests/min/IP per server instance.
| Name | Required | Description | Default |
|---|---|---|---|
| mobile_number | Yes | Phone number in any format -- "+91 98765-43210", "9876543210" and "(020) 7946 0958" all work, since +, spaces, hyphens and brackets are stripped. Must contain at least one non-zero digit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds details beyond annotations: 'Read-only deterministic arithmetic over a fixed number table -- no ephemeris, no network lookup, no writes, no auth, at least 30 req/min/IP'. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences. First sentence packs key purpose and output, second covers usage and behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one well-documented parameter, the description covers purpose, usage, behavioral traits (including rate limits), and output fields, making it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% with detailed schema description for the single parameter. Description doesn't add significant meaning beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb ('returns') and resource ('numerological reading of a mobile or landline number'), lists output components, and distinguishes from sibling tool get_numerology by clarifying it works on number strings only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use ('is my phone number lucky' questions, choosing between candidates) and when not to use ('for anything tied to a birth date use get_numerology'), naming the alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_muhurta_timingsMuhurta timings (good & bad windows)AReturns every auspicious and inauspicious time window for one date at one place, in a single call: all 16 choghadiya with quality, the 24 planetary horas, rahu kaal / yamaganda / gulika kala, abhijit + brahma + vijaya + godhuli + nishita muhurta and the two sandhyas, amrita kalam, varjyam, dur muhurtam, bhadra windows, panchak and gand mool status, and disha shool (the travel direction to avoid that weekday). Use this to CHOOSE a moment -- 'best time to sign / travel / start work today'. Use get_panchang instead when the user only wants the day's tithi and nakshatra; use get_pancha_pakshi when the timing must be personalised from full birth details. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Windows are divisions of that location's actual sunrise-to-sunset day. If a window cannot be computed for the date the result names it under data_note as unknown rather than dropping it -- do not read absence as 'none today'.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Gregorian date to compute, YYYY-MM-DD, e.g. 2026-07-25. Years 1200-2400. Omit for today's date at the given place. | |
| place | No | Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead. | |
| latitude | No | Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too. | |
| timezone | No | IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| janma_rashi | No | Birth moon sign, Sanskrit or Western -- "Vrishabha" and "Taurus" both work. Optional: supply it to add that person's chandrabala verdict for the day. Omit and the chandrabala block is left out entirely. | |
| janma_nakshatra | No | Birth star in IAST, e.g. "Rohini" or "Ashvini" (spelling is matched loosely). Optional: supply it to add that person's tarabala verdict for the day. Omit and the tarabala block is left out entirely. Get the value from get_birth_details if unknown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnly, openWorld, idempotent, and non-destructive. Description adds deterministic computation, Swiss Ephemeris, Lahiri ayanamsa, rate limits, and behavior for unknown windows (data_note). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded returns, then usage guidance, then behavioral details. Each sentence adds value, though slightly lengthy. Could be trimmed slightly without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is complex with many output windows and no output schema, but description is exhaustive: lists all windows, explains unknown behavior, provides rate limits, and covers all parameters. Complete for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 7 parameters with descriptions. Description adds context for janma_rashi and janma_nakshatra (optional, for chandrabala/tarabala) and suggests using get_birth_details if unknown. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns 'every auspicious and inauspicious time window for one date at one place' and lists specific windows. Distinguishes from siblings by naming get_panchang and get_pancha_pakshi as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool ('CHOOSE a moment') and when to use alternatives ('Use get_panchang instead...', 'use get_pancha_pakshi when...').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_numerologyVedic numerology from date of birthAReturns a Vedic numerology reading from a date of birth alone: the mulank (root / psychic number, from the day of the month) and the bhagyank (destiny / life-path number, from the whole date), each with its ruling planet and traditional meaning, plus the classical lucky attributions -- numbers, colours, weekday, direction, gemstone. Optionally adds the Chaldean naam-ank when a name is supplied. Use this when the user asks about their number, life path or lucky colour/day/stone. It is NOT astrology and shares nothing with the chart tools: for a birth chart use get_janam_kundali, for a birth star use get_birth_details. Read-only deterministic arithmetic over the classical Chaldean number table -- no ephemeris is touched, and the result's Source line says so. No writes, no auth, at least 30 requests/min/IP per server instance. Birth time and place are not used, so none is asked for.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Full name in Latin letters, e.g. "Rahul Sharma" -- it must contain at least one A-Z letter. Optional: supply it to add the Chaldean name number and its meaning; omit and only the date-derived numbers are returned. | |
| birth_date | Yes | Date of birth as YYYY-MM-DD, e.g. 1992-03-14. Must be a real calendar date. Birth time, timezone and place have no effect in numerology and are not accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context: 'Read-only deterministic arithmetic over the classical Chaldean number table -- no ephemeris is touched... No writes, no auth, at least 30 requests/min/IP per server instance.' This goes beyond annotations with rate limits and authentication details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, starting with the main purpose, then detailing outputs, usage, exclusions, and behavioral notes. Every sentence adds value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description comprehensively explains what is returned, including the source line. It covers all relevant aspects for a deterministic, read-only tool with no auth requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds meaning beyond the schema: it explains the role of each parameter (name adds Chaldean naam-ank, birth_date for date-derived numbers), provides examples, and clarifies constraints (e.g., name must contain at least one A-Z letter).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns Vedic numerology readings from date of birth, listing specific outputs (mulank, bhagyank, ruling planet, meaning, lucky attributions). It explicitly distinguishes itself from astrology and sibling tools like get_janam_kundali and get_birth_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool ('when the user asks about their number, life path or lucky colour/day/stone') and when not to use it, citing specific alternatives ('for a birth chart use get_janam_kundali, for a birth star use get_birth_details'). It also explains optional usage with a name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_panchangDaily Panchang (Hindu almanac)AReturns the Hindu panchang (daily Vedic almanac) for one date at one place: the five angas (tithi with paksha, nakshatra, yoga, karana, vara with its weekday lord) each with its end time, the lunar month in AMANTA reckoning with its adhika-masa flag (omitted entirely, never substituted, if the engine cannot supply the amanta month; plus the purnimanta month where the engine supplies it), sunrise/sunset/moonrise/moonset, abhijit muhurta, the auspicious choghadiya windows, and the inauspicious periods (rahu kaal, yamaganda, gulika kala). Use this for 'what is today's panchang / tithi / nakshatra' questions. If the user wants the FULL timing surface (all 16 choghadiya, the 24 horas, varjyam, bhadra, panchak, brahma muhurta) to choose a moment for an activity, call get_muhurta_timings instead. Nakshatra here is the DAY's nakshatra, not a person's birth star -- for that use get_birth_details. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Any city worldwide; window times derive from that location's actual sunrise and sunset, so they differ city to city on the same date.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Gregorian date to compute, YYYY-MM-DD, e.g. 2026-07-25. Years 1200-2400. Omit to get today's date at the given place (not the server's date). | |
| place | No | Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead. | |
| latitude | No | Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too. | |
| timezone | No | IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the read-only/idempotent annotations by disclosing the computation engine (Swiss Ephemeris, Lahiri ayanamsa), no auth requirement, request rate limits (30/min/IP plus shared budget), and a specific edge-case behavior ('amanta month ... omitted entirely, never substituted'). It also notes that results are location-dependent based on actual sunrise/sunset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, proceeding from return values to usage guidance to technical caveats. Every sentence conveys necessary information, though it is longer than the two-sentence ideal. The front-loading of the main output and alternatives keeps it efficient, but slight trimming could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and multiple optional parameters, the description covers all essentials: what it returns, when to use it, how parameters interact, performance characteristics, and known limitations. It even addresses edge cases like missing amanta month. No critical gap remains for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptive parameter comments, so the baseline is 3. The description adds value by explaining the relationship between parameters (e.g., 'Omit only if you pass latitude + longitude + timezone instead') and the behavioral impact of location on results ('window times derive from that location's actual sunrise and sunset'). This merits a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's function: 'Returns the Hindu panchang (daily Vedic almanac) for one date at one place' and enumerates the exact components (five angas, lunar month, sunrise/sunset, etc.). It also distinguishes from sibling tools by naming alternatives for full timing surfaces and birth-star nakshatra, making its scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear usage guidance is provided: 'Use this for "what is today's panchang / tithi / nakshatra" questions.' It explicitly tells when not to use it and what to call instead: 'If the user wants the FULL timing surface ... call get_muhurta_timings instead' and 'Nakshatra here is the DAY's nakshatra, not a person's birth star -- for that use get_birth_details.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pancha_pakshiPancha Pakshi (five-bird) timingAReturns a PERSONAL timing schedule under Tamil Pancha Pakshi Shastra: it resolves the person's birth bird (Vulture, Owl, Crow, Cock or Peacock) from their birth details, then returns that day's ten yaamas -- five by day, five by night -- each with the acting bird and activity and a list of sub-periods carrying a 1-10 strength rating plus that bird's relation (friend / same / enemy) to the person's own bird. Use this when the user wants timings tuned to THEM. get_muhurta_timings and get_panchang give the same day's windows for everyone at that place with no birth details; this system is independent of them and the two can disagree. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa for the birth-bird nakshatra); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Yaama boundaries follow the location's actual sunrise and sunset, so the schedule is place-specific.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Day to schedule, YYYY-MM-DD, years 1200-2400. Omit for today at the given place. The birth fields identify the person; this field picks the day being planned. | |
| place | No | Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead. | |
| latitude | No | Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too. | |
| timezone | No | IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| birth_date | Yes | Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected). | |
| birth_time | Yes | Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant context beyond annotations: it's a deterministic computation using Swiss Ephemeris and Lahiri ayanamsa, no writes, no auth, and specifies rate limits (30/min/IP per server instance, 60/min/IP shared). It also explains that yaama boundaries follow actual sunrise/sunset, making it place-specific. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the purpose and then provides behavioral details. It is well-structured and not overly verbose, though it could be slightly more concise by breaking into sentences. Still, it earns points for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema), the description is highly complete. It explains the output structure (yaamas, sub-periods with strength and relation), rate limits, dependency on birth details, and place-specific nature. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already has a clear description. The tool description adds a general overview but does not provide new semantics beyond what the schema already offers. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Returns a PERSONAL timing schedule under Tamil Pancha Pakshi Shastra' and specifies the verb 'Returns' and the resource. It distinguishes from siblings by noting that get_muhurta_timings and get_panchang give the same day's windows for everyone without birth details, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when the user wants timings tuned to THEM' and compares with sibling tools, explaining that this system is independent and the two can disagree. This provides clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sade_satiSade Sati (Saturn transit) statusAReturns a person's Sade Sati status -- Saturn's roughly 7.5-year passage over the sign before, the same as, and the sign after their natal Moon: whether it is currently active, the phase (rising / peak / setting) with its start and end dates, the phases still to come, the natal Moon rashi, Saturn's sign now, and dhaiya (small panoti) status. Use this for 'when does my sade sati start/end' and 'am I in shani sade sati' questions. This is Saturn-only; for where ALL nine grahas are transiting now (and their houses from the natal Moon) call get_transits. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Dates are computed, not predicted -- no interpretation of what the period will bring is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead. | |
| latitude | No | Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too. | |
| timezone | No | IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| as_of_date | No | Evaluate Saturn's position as of this date, YYYY-MM-DD, years 1200-2400. Omit for today. Use it to ask 'was I in sade sati in 2019' or 'will I be in 2031'. | |
| birth_date | Yes | Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected). | |
| birth_time | Yes | Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds specifics: deterministic Swiss Ephemeris computation, Lahiri ayanamsa, no writes, no auth, rate limits, and that dates are computed not predicted. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs: first defines output and usage, second covers scope/constraints. Front-loaded with most important info, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description enumerates all return fields (phase, dates, dhaiya, etc.). Covers rate limits, deterministic nature, and provides sibling guidance. Complete for complex tool with 7 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but description adds critical context: for place/lat/lon/timezone it explains fallback; for birth_time warns about ascendant sensitivity; for as_of_date gives usage examples. Adds value beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it returns Sade Sati status with specific outputs (phase, dates, dhaiya) and distinguishes from sibling tool get_transits by calling out that get_transits covers all grahas. Use examples like 'when does my sade sati start/end' clarify purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this for ...' and 'This is Saturn-only; for where ALL nine grahas are transiting now... call get_transits', giving clear when-to-use and when-not-to-use with an alternative tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transitsPlanetary transits (gochar) now or on a dateAReturns where the nine grahas actually are at a moment in time (gochar / transit chart), for a place: each graha's sidereal sign, degree within the sign, nakshatra, pada, retrograde flag, dignity and house from the transit ascendant, plus the transit lagna itself. Defaults to right now at that place. Pass the optional natal birth details and the result ALSO counts each transiting graha's whole-sign house from the natal Moon (chandra lagna) -- the frame classical gochar is read in. Use this for 'where is Saturn/Jupiter right now' and 'what is transiting my moon sign' questions. It answers for ONE moment only and returns no ingress, retrograde-station or sign-change dates -- do not scan it across many dates to find them. For the birth chart itself use get_janam_kundali; for dated Saturn phases use get_sade_sati, the one tool here that returns transit date ranges. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa, whole-sign houses); no writes, no auth. Rate limits are counted per server instance: at least 30 requests/min/IP on this endpoint, plus a shared engine budget of at least 60/min/IP across all chart tools -- and a call carrying natal costs TWO of those, since it computes the natal chart as well. It returns COMPUTED POSITIONS ONLY -- no forecast, horoscope or interpretation text is produced.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date of the transit chart, YYYY-MM-DD, years 1200-2400. Omit for today at the given place. A past or future date gives the positions for that single day. | |
| time | No | Local clock time of the transit chart, HH:MM 24-hour (00:00-23:59). Omit for the current time at the given place. It matters most for the Moon (about 13 degrees a day) and for the transit lagna (a full sign every two hours); the slow grahas barely move within a day. | |
| natal | No | Optional birth details of the person the transits are being read for: birth_date, birth_time and a place (or latitude + longitude + timezone). Supply them to add the gochar_from_natal_moon block. Omit and only the sky positions are returned. | |
| place | No | Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead. | |
| latitude | No | Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too. | |
| timezone | No | IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description explains it is read-only deterministic computation using Swiss Ephemeris, Lahiri ayanamsa, whole-sign houses, with no writes or auth. It also discloses rate limits (30 req/min/IP per endpoint and shared engine budget). Annotations already indicate safe operations; description adds specific context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with core purpose, then expands on details, use cases, limitations, and technical aspects. Every sentence provides useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description lists what is returned (positions for each graha, transit lagna, optional natal moon houses) and what is not (forecast, interpretation). It covers all necessary context for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The tool description adds value by explaining the effect of providing the optional 'natal' parameter (adds houses from natal moon) and why time matters (Moon moves ~13 deg/day, lagna changes quickly). This goes beyond basic schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns transit positions (gochar) for nine grahas at a specific moment, including details like sign, degree, nakshatra, etc. It distinguishes itself from siblings by explicitly naming get_janam_kundali for birth charts and get_sade_sati for transit date ranges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: for 'where is Saturn/Jupiter right now' and 'what is transiting my moon sign'. Also warns against scanning across dates because it returns only one moment. Names alternative tools for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_upapada_arudhaUpapada lagna and arudha padas (Jaimini)AReturns the Jaimini layer of one birth chart: the upapada lagna (UL, the classical marriage anchor) with its sign, lord and cited reading, all twelve arudha padas (A1-A12) with sign and life domain, the eight charakarakas (Atmakaraka, Amatyakaraka and the rest) with the graha holding each, and the karakamsha lagna. The result also lists the classical texts the upapada reading is cited from. Use this only when Jaimini terms are asked for by name -- upapada, arudha, charakaraka, karakamsha -- or for marriage questions read the Jaimini way. The Parashari layer (grahas, houses, dasha, yogas) is in get_janam_kundali; get_kundli_match is the tool for scoring two charts against each other. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth. Rate limits are counted per server instance: at least 30 requests/min/IP on this endpoint, plus a shared engine budget of at least 60/min/IP across all birth-chart tools. If the engine cannot attach the Jaimini layer the result comes back with partial: true rather than with invented values.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | Place as free text, "City, State, Country" -- e.g. "Jaipur, Rajasthan, India". Preferred input: it is geocoded to coordinates and an IANA timezone server-side, and any city worldwide works. Omit only if you pass latitude + longitude + timezone instead. | |
| latitude | No | Latitude in decimal degrees, -90 to 90, north positive (Delhi = 28.6139). Use only when `place` is omitted, and then longitude and timezone are required too. | |
| timezone | No | IANA timezone name, e.g. "Asia/Kolkata" or "America/New_York" (never an offset like "+05:30"). Required when latitude/longitude are used; ignored when `place` is given. | |
| longitude | No | Longitude in decimal degrees, -180 to 180, east positive (Delhi = 77.2090). Use only when `place` is omitted. | |
| birth_date | Yes | Birth date in the Gregorian calendar as YYYY-MM-DD, e.g. 1992-03-14. Years 1200-2400 only, and it must be a real calendar date (2023-02-29 is rejected). | |
| birth_time | Yes | Birth time on the local clock at the birth place, HH:MM in 24-hour format (00:00-23:59), e.g. 06:45 or 18:20. Not UTC. Required and not defaulted: the ascendant moves about one degree every four minutes, so a guessed time gives a guessed chart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds further transparency: 'Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa); no writes, no auth.' It also explains rate limits and partial result behavior ('partial: true rather than with invented values'), which are critical for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with the most important information first. It is somewhat lengthy but each sentence adds value, covering purpose, usage, behavior, and fallback. It is not overly verbose for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (Jaimini layer, multiple return components) and the absence of an output schema, the description thoroughly explains what is returned, including fallback behavior. It also covers rate limits and usage context, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with each parameter having a clear description. The tool description does not add additional parameter semantics beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts by specifying exactly what the tool returns: upapada lagna, twelve arudha padas, eight charakarakas, and karakamsha lagna. It explicitly distinguishes this Jaimini layer from Parashari tools (get_janam_kundali, get_kundli_match), making the purpose clear and differentiating it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this only when Jaimini terms are asked for by name... or for marriage questions read the Jaimini way.' It names alternatives (get_janam_kundali, get_kundli_match) and states when not to use this tool, covering both conditions and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_year_eventsHindu festival & vrat dates for a yearAReturns dated Hindu calendar events for a whole year at one city. category='festival' lists every festival and vrat that year (Holi, Diwali, Navratri, Shivratri and the rest); the other categories list every ekadashi, purnima, amavasya or sankranti date. Each row is the exact local date and the event name, plus a one-line significance on shorter lists. Use this for 'when is X this year' and 'list all ekadashi dates' questions. For the detail of a single day (tithi, sunrise, rahu kaal) call get_panchang with that date; for eclipses call get_eclipses. Read-only deterministic computation (Swiss Ephemeris, Lahiri ayanamsa), served from a shared cache -- a cold or expired entry recomputes and can take ~30s; no writes, no auth, at least 30 requests/min/IP per server instance, plus a shared engine budget of at least 60/min/IP across all engine-backed tools. Constraints: the year must be within two years either side of the current year, and results are computed for the nearest of 50 supported cities (a location_note names it when the snap is far); long lists are capped at 80 rows, so pass month to page through them.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Gregorian calendar year as a number, e.g. 2026. Only the current year plus or minus two is supported; anything else is rejected. | |
| month | No | Restrict the result to a single Gregorian month, 1 = January to 12 = December. Omit for the whole year. Use it when a year-wide list came back truncated. | |
| place | No | City as free text, e.g. "Jaipur" or "Chennai, India". Omit to use Delhi. Any input is snapped to the nearest of 50 supported cities, since tithi-based dates can differ by a day between distant longitudes. | |
| category | Yes | "festival" returns every event of the year; "ekadashi", "purnima", "amavasya" and "sankranti" each narrow the list to that lunar/solar family only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only deterministic computation, cache behavior with ~30s cold start, no writes, no auth, and specific rate limits per IP per instance and shared engine budget. This adds beyond annotations which only state readOnlyHint, idempotentHint, and destructiveHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive but slightly long. Every sentence earns its place, covering purpose, usage, behavior, and parameters. Could be marginally condensed, but structure is logical and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains return format (date, event name, significance) and pagination via month parameter. Covers constraints, rate limits, caching, and city snapping, making it complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the description adds context on month usage for paging, place snapping logic, category narrowing, and year constraints. It explains why place is snapped and how to handle truncated results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns dated Hindu calendar events for a whole year at one city, with specific event categories. It distinguishes from sibling tools like get_panchang and get_eclipses by contrasting use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (e.g., 'when is X this year', 'list all ekadashi dates') and when not to use (e.g., for single day detail call get_panchang, for eclipses call get_eclipses). Also specifies constraints like year range and 80-row limit with month paging.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.