Western zodiac sign from date of birth and sign compatibility scores. English and Hindi.
Scored across 2 tools
check_compatibility and get_zodiac_sign target clearly different tasks: scoring a pair of signs vs. resolving a birth date to a single sign. There is no overlap in inputs or outputs, so an agent can select correctly without hesitation.
Both tools use a clean snake_case verb_noun convention (check_compatibility, get_zodiac_sign) with predictable semantics. No mixing of styles or vague verbs.
Two tools is on the thin side, but the server's scope is deliberately narrow (sign lookup plus pair compatibility), and both tools earn their place. A slightly broader surface (e.g. listing signs) would round it out.
Core lifecycle is covered: date-to-sign resolution and a fully specified compatibility scorer with documented methodology, plus cusp handling and bilingual names. Minor gaps remain, such as a list-all-signs operation or a direct sign-to-sign-metadata lookup, but agents can work around these using get_zodiac_sign.
Score two signs 0-100 with the published rule: element base (same 80; fire-air 85; earth-water 85; fire-earth 45; fire-water 40; earth-air 50; air-water 55), modality same -5 / different +5, no modality adjustment for a sign with itself (same sign = 75), clamp and round; symmetric. Bands: 80+ strong, 65-79 good, 50-64 mixed, <50 challenging. Returns score, band, verdict (one line per band), elements, modalities, method_url '/guides/how-compatibility-is-scored', page_url. Case-insensitive; Hindi sign names accepted. Example input: {"sign_a":"Aries","sign_b":"Leo"}
| Name | Required | Description | Default |
|---|---|---|---|
| sign_a | Yes | First sign, English or Hindi | |
| sign_b | Yes | Second sign, English or Hindi |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does well: discloses the exact deterministic algorithm, symmetry, clamping/rounding, band thresholds, and the returned fields. It does not state failure behavior for unrecognized sign strings or confirm there are no side effects / external lookups, which matters for free-text inputs with no enums.
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?
Front-loaded with the action and zero wasted sentences — every clause (rule, bands, return fields, URLs, input example) earns its place. The single densely packed paragraph makes the band and return-value details harder to scan than a short structured list would, which keeps it below a 5.
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?
With no output schema and no annotations, the description must carry everything, and it nearly does: return fields, band meanings, verdict, and method/page URLs are all enumerated. The notable gap is error/edge-case handling for invalid sign names, which the schema cannot express since there are no enums.
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 baseline is 3, but the description adds real value: 'symmetric' tells the agent sign_a/sign_b order is irrelevant, and the example input plus 'case-insensitive; Hindi sign names accepted' clarifies accepted value space beyond the schema's min/max length constraints.
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?
Opens with a specific verb and resource: 'Score two signs 0-100 with the published rule'. That is unambiguously a compatibility scorer, distinct from the sibling get_zodiac_sign lookup, so an agent can select between them without opening a schema.
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 strong usage context (accepted input forms, an example input, the published formula, and a method_url) but never explicitly states when to invoke this versus the sibling tool or what happens if the caller only has one sign. Clear context, no exclusions — a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Western sun sign from a date of birth (year optional, ignored). Returns sign slug, name_en, name_hi, start, end, element, modality, ruler, is_cusp (first or last day), cusp_neighbour, convention 'standard calendar dates', url. Validation error for impossible dates like 02-30. Example input: {"month":7,"day":23,"lang":"en"}
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | Day of birth, 1 to 31 | |
| lang | No | Language of the sign name in url: en or hi | en |
| month | Yes | Month of birth, 1 to 12 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it enumerates the return fields, explains is_cusp and cusp_neighbour, pins the convention ("standard calendar dates"), and discloses that impossible dates like 02-30 produce a validation error. It does not state whether the tool is a pure read with no side effects or note any limits on input elsewhere, which keeps it off a 5.
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 purpose comes first, then the payload, then the error case, then an example — a sensible front-loaded order with no filler sentences. The middle return-field list is dense but earns its place because no output schema exists.
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 three simple parameters and no output schema, the description covers everything an agent needs: how to call it, what fields come back, how cusp days behave, and how invalid dates fail. The only wrinkle is the stray "year" reference, which does not undermine the overall sufficiency.
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: month, day and the lang enum are already fully documented in the schema and the description adds only the example usage. The mention of "year optional, ignored" refers to a parameter that does not exist in the schema, which mildly muddies rather than clarifies the parameter surface.
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?
Opens with a specific resource and derivation rule ("Western sun sign from a date of birth"), and the described return payload (element, modality, ruler, cusp) confirms exactly what kind of sign data this is. It is trivially distinguishable from the only sibling, check_compatibility, which compares people rather than deriving a sign.
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 context for use: a birth month/day produces one sun sign, year is explicitly optional and ignored, and a worked example input is supplied. It stops short of stating exclusions (e.g. what to do for dates the caller is unsure about, or that this is not for compatibility), so it falls just under the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_compatibilityget_zodiac_signVedic and Western astrology for AI agents: charts, dasha, matchmaking, panchanga, numerology, tarot.
Daily horoscopes (en/es/pt, 7 days ahead), moon phases, Panchang, solar terms, Maya, Ramadan dates.
Vedic astrology from a real ephemeris: birth chart, life-event timing and Kundli matching.
Vedic kundli, daily sky, kundli milan, sade sati and mangal dosha from birth details.
Add one secure layer between your agents and this server.
