Zodiac Compatibility

Check sign compatibility

check_sign_compatibility

Read-onlyIdempotent

Returns how two zodiac signs match: a verdict label, the wheel aspect and its angle, the elements and modalities, and one line each for love, friendship and work. Accepts two signs, or two birth dates whose Sun signs are read by month and day; a birthday near a sign change returns the possible pairs.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_sign_compatibility"
  }
}

Input Schema

Name	Required	Description
`firstSign`	No	First zodiac sign, such as Aries or Pisces, in any letter case.
`secondSign`	No	Second zodiac sign, such as Leo or Capricorn, in any letter case.
`firstBirthDate`	No	First person's birth date as YYYY-MM-DD, from 1900 to 2100; only the month and day are used.
`secondBirthDate`	No	Second person's birth date as YYYY-MM-DD, from 1900 to 2100; only the month and day are used.

Output Schema

Name	Required	Description	Default
`item`	Yes
`view`	Yes
`request`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover readOnly, idempotent, non-destructive and closed-world, so the bar is lower, and the description still adds real behavior: only month and day of a birth date matter, and a birthday near a sign change returns the possible pairs rather than one answer. What it omits is failure handling for unrecognized sign strings and what happens with zero arguments, given all parameters are optional.

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?

Two dense sentences with no filler, and the payoff (what is returned) is stated first. Leading with the return shape rather than the call purpose is slightly unconventional but does not waste words.

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

Completeness3/5

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

An output schema exists, so the description does not need to enumerate return fields, yet it does so helpfully. The real gap is invocation ambiguity: all four parameters are optional and the definition never states which subset must be supplied for a valid call, or how a sign and a birth date interact.

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% and the schema already documents each field's format and case-insensitivity, so baseline is 3. The description adds meaning beyond that by framing the parameters as two alternative input pairs and by explaining that birth dates are decomposed to month and day, which drives the cusp/pairs behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource ('Returns how two zodiac signs match') and enumerates the actual payload (verdict, aspect and angle, elements, modalities, love/friendship/work lines), so the agent knows precisely what it gets. It does not differentiate itself from plausible siblings such as get_synastry or get_sign_profile, which keeps it below a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description names two accepted input modes (two signs, or two birth dates) and hints at a cusp case, which implies usage. However it never states when to pick this over get_synastry or get_sign_profile, nor whether sign and birth-date inputs can be mixed, so the guidance is implied rather than explicit.

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

All Zodiac Compatibility tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.