Skip to main content
Glama
Sign In

Cosmic Chemistry

by co.cosmicchemistry
OverviewDiscussionsAdmin

Manglik (Mangal dosha) check

manglik_check
Read-onlyIdempotent

Use this when someone asks if they are Manglik or have Mangal dosha. Returns where Mars falls counted from the rising sign, the Moon and Venus, and which of those counts show it. Present it honestly: about half of all charts count as Manglik by the common rule, so it is common, not a danger. Works from the birth date and town; the birth time adds the main count, from the rising sign.

Input Schema

NameRequiredDescriptionDefault
birth_dateYesDate of birth, YYYY-MM-DD, e.g. 1993-03-17.
birth_timeNoLocal clock time of birth, 24-hour HH:MM, e.g. 13:35. As exact as possible (from a birth certificate).
birth_placeYesTown or city of birth, with region or country if known, e.g. "Chicago, Illinois, US" or "Pune, India".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / required
      Previous value: -[
-  "birth_date",
-  "birth_time",
-  "birth_place"
-]New value: +[
+  "birth_date",
+  "birth_place"
+]
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real value: it discloses what is returned (Mars position from the rising sign, Moon and Venus, and which counts flag it) and warns that the birth time drives the main count. It also sets interpretive expectations ('about half of all charts count as Manglik'), which is behaviorally useful. It stops short of covering error handling or result formatting.

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?

Four sentences, front-loaded with the triggering question before the mechanics and the interpretive caveat. Each sentence carries distinct information, with only minor redundancy around the birth-time dependency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still explains what the tool returns and how accuracy depends on inputs, which is adequate for a 3-parameter read-only check. Only the response shape and edge cases (e.g. unknown birth time) are left implicit.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining that birth date and town are sufficient while birth time supplies the main rising-sign count. That tells an agent why the optional parameter matters.

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 ('check' whether someone 'is Manglik or has Mangal dosha') and names the exact question it answers. It is clearly distinguishable from siblings like birth_chart_compatibility or sade_sati_check.

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?

Opens with an explicit trigger: 'Use this when someone asks if they are Manglik or have Mangal dosha.' That gives clear usage context, though it does not name the nearest alternative (e.g. compatibility matching) or state when-not to use it.

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

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources