astroway-mcp

Official

by astroway

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

MCP Multi-Chart Context

astroway_mcp_multi_chart_context

Read-only

Builds compact astrological context from up to six natal charts so MCP agents can analyze compatibility, family, group, or forecast scenarios in one request.

Instructions

Compact context for MCP agents working across multiple charts.

[Group: AI & MCP] [Endpoint: POST /v1/mcp/multi-chart-context] [Required: charts] [Cost: 10 credits (Tier 1)]

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": {
      "charts": "<charts>"
    },
    "name": "astroway_mcp_multi_chart_context"
  }
}

Input Schema

Name	Required	Description	Default
`charts`	Yes
`intent`	No

Output Schema

Name	Required	Description	Default
`notes`	No
`intent`	No
`summaries`	No
`chartCount`	No
`contextHash`	No
`summaryString`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.6.1Nov 9, 2026

changedInput schema / properties / charts / items / description

Previous value: -"Birth data for a single natal chart. Required: date (YYYY-MM-DD), time (HH:mm:ss), latitude and longitude in decimal degrees. The short forms lat, lon, lng and tz are rejected with 400 INVALID_FIELD; pass the full names. timezoneOffset is hours from UTC and defaults to 0, meaning UTC; send timezone instead (an IANA name such as Europe/Kyiv, or auto) and the offset for that date is worked out, summer time included. city is a display label only: nothing here geocodes it, so it never stands in for coordinates. houseSystem is a single Swiss Ephemeris letter, P by default; a name such as \"Placidus\" is refused, and the case matters because I and i are two different Sunshine systems."New value: +"Birth data for a single natal chart. Required: date (YYYY-MM-DD), time (HH:mm:ss), latitude and longitude in decimal degrees. The short forms lat, lon, lng and tz are rejected with 400 INVALID_FIELD; pass the full names. timezoneOffset is hours from UTC and defaults to 0, meaning UTC; send timezone instead (an IANA name such as Europe/Kyiv, or auto) and the offset for that date is worked out, summer time included. city is a display label only: nothing here geocodes it, so it never stands in for coordinates. houseSystem is a single house-system letter, P by default; a name such as \"Placidus\" is refused, and the case matters because I and i are two different Sunshine systems."

Addedv1.6.0Oct 24, 2026

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds two things not in annotations: the cost (10 credits, Tier 1) and the endpoint/group metadata, which are genuinely useful for budgeting calls. It still says nothing about what 'context' comprises, any limit implications of the 1-6 chart range, or latency.

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?

It is short and front-loaded with the one-line purpose before the bracketed metadata. The bracket block is boilerplate but compact and factual (group, endpoint, required param, cost); no sentence is padding beyond that.

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

Completeness2/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 spelled out. However, the core semantics of a multi-chart aggregation tool — what 'context' means, whether charts are compared or merely batched, and what 'intent' selects — are left entirely unexplained, which is inadequate for a tool with an enum-driven behavior switch.

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

Parameters2/5

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

Top-level schema description coverage is 0%: the 'charts' array has no description and 'intent' is an unexplained enum (compatibility, family, group, forecast). The description only restates that charts is required, adding no meaning about how many charts to send, whether they must be related, or what each intent value changes. The rich nested birth-data description in the schema does most of the work, but the description itself contributes nothing.

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

Purpose3/5

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

The phrase 'Compact context for MCP agents working across multiple charts' names the resource (multi-chart context) but uses a vague noun 'context' and no concrete verb, so an agent cannot tell what is actually produced (combined summary, cross-chart aspects, group report?). It does distinguish itself implicitly from single-chart tools by 'across multiple charts', but only loosely.

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 guidance, no when-not-to-use, and no named alternative among the many sibling chart tools. The only operational hints are 'Required: charts' and a credit cost, which do not tell an agent when this is preferable to a single-chart or synastry call.

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

Deploy Server