Skip to main content
Glama

AstroWay Astrology API (full catalogue)

Generate Chinese Year Forecast (PDF or HTML)

astroway_reports_chinese_year

A Chinese zodiac year forecast as an A4 PDF (default), HTML or Markdown: your animal and the element of your birth year with their characterisation, the pillar of the year asked for with its exact Lichun dates, how the year's branch stands to yours (your own year 本命年, the clash 冲太岁, harmony, trine, harm or neutral) and how its element stands to yours, your allies and opposites, and the twelve solar months with their pillars and their relation to your branch. Animal from /chinese/zodiac/animal, boundaries from the ephemeris. year defaults to next calendar year.

[Group: Reports] [Endpoint: POST /v1/reports/chinese-year] [Required: date] [Cost: 5,000 credits (Tier 7)] ⚠️ Premium — ~50% of free monthly budget. Confirm with user before invoking.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "date": "<date>"
    },
    "name": "astroway_reports_chinese_year"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateYes
nameNoPrinted on the cover.
timeNoBirth time; decides the animal for a birth within a day of Lichun.
yearNoThe Chinese year read, counted from its Lichun. Defaults to next calendar year.
fieldsNoCompact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response.
formatNo`pdf` (default) stores a PDF and answers with its `url`. `html` returns one self-contained `text/html` document, `markdown` returns `text/markdown` with the same sections and tables; neither is stored. Same price in every format.
languageNo
timezoneNoIANA zone name such as Europe/Kyiv, or auto to look the zone up from latitude and longitude. The server takes the offset that zone kept at this local date and time, summer time included, and uses it in place of timezoneOffset. A clock time that happened twice takes the first occurrence; one skipped when clocks went forward takes the offset from before the change. Abbreviations such as EST are refused. Before 1970 the tz database is not reliable for every place, so send timezoneOffset when the local clock is known.
precisionNoCompact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn.
whitelabelNo
timezoneOffsetNoHours from UTC at the given moment, not minutes. Fractional zones are hours too: 5.5 for India, 5.75 for Nepal, -3.5 for Newfoundland. Defaults to 0, meaning UTC. Ignored when timezone is sent.

Output Schema

NameRequiredDescriptionDefault
urlNo
expires_atNo
page_countNo
byte_lengthNo
duration_msNo
storage_keyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the side effects that matter: `pdf` stores a file and answers with a `url` while `html`/`markdown` are self-contained and not stored, and the price is identical across formats. The appended cost line (5,000 credits, Tier 7, ~50% of a free monthly budget, confirm first) is exactly the kind of pre-invocation warning the agent needs and is consistent with readOnlyHint=false / openWorldHint=true.

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?

Purpose and format come first, and the trailing default and cost notes are placed where they will be seen. The opening sentence is a long comma-chained run-on that is dense to parse, which is the main deduction; nothing is outright redundant, since the format and cost statements add information the schema does not.

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?

An output schema exists, so return values need not be explained, and the description still clarifies the PDF-vs-inline distinction that matters for handling the result. For an 11-parameter, premium-priced report generator it covers content, formats, storage behavior, defaults and cost — enough for an agent to invoke it correctly and warn the user.

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?

With 73% schema description coverage, the schema already carries most parameter meaning. The description only adds provenance notes ('Animal from /chinese/zodiac/animal, boundaries from the ephemeris') and restates the `year` default that the schema itself documents; the seven other parameters (date, time, fields, whitelabel, language, precision, timezone) get no treatment in the description. Baseline 3 is appropriate.

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 first sentence names a specific artifact (a Chinese zodiac year forecast report) and enumerates its exact sections — animal and birth-year element, the year pillar with Lichun dates, branch relation (本命年, 冲太岁, harmony, trine, harm), element relation, allies/opposites, and the twelve solar months. It also states the deliverable formats, so an agent can distinguish this from calculation siblings such as astroway_chinese_zodiac_animal or astroway_bazi_year_pillar, which return data rather than a document.

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?

Usage is implied through defaults ('`year` defaults to next calendar year', '`pdf` (default)') and the appended cost gate 'Confirm with user before invoking', which is genuine when-to-call guidance. However, there is no explicit comparison against the many sibling report tools (astroway_reports_bazi, astroway_reports_natal, etc.) to say which report to pick for a given user request.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources