RoxyAPI Astrology MCP server

Official

by RoxyAPI

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Compatibility score - Relationship compatibility API

post_astrology_compatibility_score

Read-only

Calculate a 0-100 compatibility score between two birth charts using Western synastry. Get category breakdowns for romantic, emotional, intellectual, physical, and spiritual fit.

Instructions

Calculate a detailed compatibility score between two birth charts using Western synastry (inter-chart aspects). Returns overall score (0-100) plus category breakdowns for romantic, emotional, intellectual, physical, and spiritual compatibility. Each category analyzes specific planetary pairs: Venus-Mars for romance, Moon-Moon for emotions, Mercury-Mercury for intellect. Includes Sun, Moon, Venus, and Mars sign compatibility narratives, element balance analysis, relationship archetype classification, and the most significant inter-chart aspects with relationship-specific interpretations.

Input Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`compact`	No	Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.
`person1`	Yes	First person birth details (date, time, location, timezone). Required for calculating natal planetary positions.
`person2`	Yes	Second person birth details. Compared against person1 to evaluate inter-chart aspects and compatibility.

Output Schema

Name	Required	Description	Default
`persons`	Yes
`summary`	Yes
`archetype`	Yes
`strengths`	Yes
`categories`	Yes
`challenges`	Yes
`keyAspects`	Yes
`overallScore`	Yes
`elementBalance`	Yes
`interpretation`	Yes
`aspectBreakdown`	Yes
`signCompatibility`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.1.2Oct 5, 2026

changedInput schema / examples

Previous value: -[
-  {
-    "person1": {
-      "date": "1990-07-15",
-      "latitude": 40.7128,
-      "longitude": -74.006,
-      "time": "14:30:00",
-      "timezone": -5
-    },
-    "person2": {
-      "date": "1990-07-15",
-      "latitude": 40.7128,
-      "longitude": -74.006,
-      "time": "14:30:00",
-      "timezone": -5
-    }
-  }
-]New value: +[
+  {
+    "person1": {
+      "date": "1990-07-15",
+      "latitude": 40.7128,
+      "longitude": -74.006,
+      "time": "14:30:00",
+      "timezone": "America/New_York"
+    },
+    "person2": {
+      "date": "1990-07-15",
+      "latitude": 40.7128,
+      "longitude": -74.006,
+      "time": "14:30:00",
+      "timezone": "America/New_York"
+    }
+  }
+]

changedInput schema / properties / person1 / properties / timezone / example
```
Previous value: --5New value: +"America/New_York"
```
changedInput schema / properties / person2 / properties / timezone / example
```
Previous value: --5New value: +"America/New_York"
```

First observedv0.1.0Oct 4, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that this is a scored, interpretive analysis (0-100 score, category breakdowns, narratives), which is useful, but it discloses no operational traits such as cost, rate limits, or what happens with missing/unknown birth times beyond the schema's own note.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first clause, but the bulk of the text is an enumeration of return contents that the output schema already defines (categories, narratives, element balance, archetype, aspects). That enumeration is largely redundant against the existing output schema and could be trimmed without losing agent-relevant signal.

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?

An output schema exists, so return values need not be explained, and the definition is otherwise thorough about the tool's scope. The one real gap is the absence of any routing contrast against sibling tools that consume the same birth-chart inputs.

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

Parameters3/5

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

Schema description coverage is 100%, and the nested person1/person2 objects are fully documented in the schema itself, so the description carries no additional parameter burden. The description adds nothing beyond what the schema already states, warranting the baseline 3.

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?

The description states a specific verb and resource: 'Calculate a detailed compatibility score between two birth charts using Western synastry.' It is unambiguous what the tool produces. It stops short of naming the sibling it competes with (post_astrology_synastry, post_astrology_composite_chart), so an agent must infer the boundary between a scored relationship analysis and raw inter-chart aspects.

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

Usage Guidelines2/5

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

There is no when-to-use or when-not-to-use guidance. With three sibling relationship-analysis tools (synastry, composite_chart, compatibility_score), the definition never says when the scored/interpreted view is preferable to the raw aspect output. The agent is left to infer routing purely from the name.

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

Deploy Server