Feng Shui MCP Server by RoxyAPI

Monthly flying stars - Month by month feng shui overlay API

get_feng_shui_flying_stars_monthly

Read-only

Return the monthly flying star plate, the faster overlay that sits on top of the annual one. Months here are SOLAR months: month 1 begins at Li Chun in early February and each month begins at the next of the twelve major solar terms, so they never line up with calendar months. Omit both parameters to get the month in progress. Built for monthly guidance features and for timing work around an affliction that only lands for part of the year.

Input Schema

TableJSON 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
`year`	No	Solar year, 1900 to 2100. Defaults to the solar year in progress, which changes at Li Chun rather than on 1 January.
`month`	No	Solar month, 1 to 12, where 1 begins at Li Chun in early February. This is NOT the calendar month: solar month 1 covers roughly 4 February to 5 March. Defaults to the solar month in progress.
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`year`	Yes
`month`	Yes
`palaces`	Yes
`centerStar`	Yes
`yearBranch`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "centerStar": {
+      "type": "number"
+    },
+    "month": {
+      "type": "number"
+    },
+    "palaces": {
+      "items": {
+        "properties": {
+          "element": {
+            "type": "string"
+          },
+          "enhancer": {
+            "type": "string"
+          },
+          "meaning": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "nameLocalized": {
+            "type": "string"
+          },
+          "nature": {
+            "type": "string"
+          },
+          "palace": {
+            "type": "string"
+          },
+          "remedy": {
+            "type": "string"
+          },
+          "star": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "palace",
+          "star",
+          "name",
+          "element",
+          "nature",
+          "enhancer",
+          "remedy",
+          "meaning"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "year": {
+      "type": "number"
+    },
+    "yearBranch": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "year",
+    "month",
+    "centerStar",
+    "yearBranch",
+    "palaces"
+  ],
+  "type": "object"
+}

First observedSep 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With readOnlyHint=true and destructiveHint=false already covering the safety profile, the description adds meaningful behavioral context: solar months follow the twelve major solar terms, never align with calendar months, and omitting parameters yields the current month. It also flags the API as a 'faster overlay,' a useful performance and composition trait.

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

Conciseness5/5

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

Three substantive sentences with the core result front-loaded and the non-obvious solar-month caveat placed immediately after. Every sentence earns its place, with no filler or unnecessary repetition of schema details.

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

Completeness5/5

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

Given a 100%-covered input schema, an output schema, and read-only annotations, the description covers the domain-specific ambiguity around solar months, default behavior, and intended use. Nothing an agent needs to call this tool correctly is missing.

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?

The input schema fully documents all four parameters with defaults, ranges, enums, and examples, so the description does not need to carry the schema. It still adds value by clarifying the solar-month model and by stating the combined default behavior when both parameters are omitted.

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?

The description opens with a concrete verb-resource pair ('Return the monthly flying star plate') and immediately distinguishes it from the annual concept by calling it 'the faster overlay that sits on top of the annual one.' This clearly separates it from sibling tools like get_feng_shui_flying_stars_annual_year.

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?

The description identifies specific use cases: 'monthly guidance features' and 'timing work around an affliction that only lands for part of the year.' It also explains the default invocation ('Omit both parameters to get the month in progress'), though it does not explicitly name an alternative tool 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 Feng Shui MCP Server by RoxyAPI 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.

Resources

Need Help?