Archetypes, Jungian typology, shadow work and the relationship-style readings.
Scored across 45 tools
Many tools are explicit aliases of each other (e.g. astroway_psya_cycle_of_becoming and astroway_psychological_modern_arroyo_cycle_of_becoming), giving identical functionality under different names. The agent/AI tools (mcp_ai_chat, mcp_agent_debate, multi_agent_coordinate, rag_search, streaming, tool_call_stream) also overlap heavily with vague boundaries, making selection error-prone.
Prefixes vary unpredictably: astroway_account_status, astroway_mcp_ai_chat, astroway_psya_*, astroway_psychological_modern_arroyo_*, astroway_psyg_*, astroway_psyr_*. Abbreviated alias prefixes (psya, psyg, psyr) coexist with long-form names for the same underlying operations, and 'mcp' appears inconsistently in the middle of several names.
45 tools is already excessive for the apparent scope, and roughly 30 of them are duplicate aliases of 15 unique psychological endpoints. Only about 15 unique capabilities exist, so the count is inflated by redundant naming rather than earning its place.
The server focuses on psychological interpretations and agent infrastructure but lacks obvious core astrology operations such as computing a natal chart, generating transits, synastry calculation, or managing saved charts. There are significant gaps in the fundamental lifecycle for an astrology domain.
Check current API key status: tier, credit balance, rate limits, monthly cycle reset. Run this BEFORE invoking expensive endpoints (Tier 4+ at 100+ credits, Tier 6/7 at 500-5000 credits) to confirm the user has budget. Returns plain-text human-readable summary.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds that it returns a 'plain-text human-readable summary' and clarifies the budget-checking purpose, providing useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences: purpose, usage guidance, and return format. Front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description specifies the return format (plain-text human-readable summary). For a simple status check tool, this is complete and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so schema coverage is 100%. Description does not need to explain parameters, and it adds value by hinting at the output format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Check' and the resource 'API key status' with specific attributes (tier, credit balance, rate limits, monthly cycle reset). It distinguishes itself from the many sibling astrology calculation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to run this tool BEFORE invoking expensive endpoints, providing credit thresholds (Tier 4+ at 100+ credits, Tier 6/7 at 500-5000 credits) to confirm budget.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool definitions for an agent framework, generated from the live OpenAPI document, so the schema a model fills is the schema the endpoint validates. format=openai (default) returns { type, function } objects you can spread straight into a chat completion; format=anthropic returns { name, description, input_schema }. The objects carry nothing of ours: how to call each t…
[Group: Agent Platform] [Cost: see your plan — endpoint not in the public credit manifest]
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text filter applied within the selection, matched against path, summary, description and group. | |
| limit | No | How many tools to return. The ceiling is the OpenAI limit of 128 functions per request; models degrade well before it. Anything left out is counted in `totalMatched`. | |
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| format | No | Which vendor contract the tool objects follow. `openai` returns `{ type, function }`, `anthropic` returns `{ name, description, input_schema }`. | openai |
| select | No | What to hand over: `starter` (the curated set, the default), `all`, `group:<tag>` such as `group:Vedic`, or `paths:/chart,/synastry` for an explicit list. An unknown path is named in `notes` rather than dropped. | starter |
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. |
| Name | Required | Description |
|---|---|---|
| count | No | |
| notes | No | |
| tools | No | |
| format | No | |
| select | No | |
| executors | No | |
| truncated | No | |
| totalMatched | No | |
| totalAvailable | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds the useful guarantee that the emitted schema is the schema the endpoint validates and that the objects carry no vendor-specific fields, but says nothing about cost, rate limits, or response size behavior beyond what the schema states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The visible portion is front-loaded on what is returned and the two format shapes, with no filler. It is somewhat terse for a tool with six parameters and a listed default/select semantics, but every visible sentence carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values, and annotations cover the read-only/idempotent profile. The remaining gap is routing: nothing tells the agent when to choose this over astroway_mcp_tools_list or similar listing tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every one of the six parameters is already documented in the schema, including the format enum and the select/fields/precision semantics. The description restates the format option rather than adding new meaning, so the baseline 3 for full schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: returning agent tool definitions generated from the live OpenAPI document, in either OpenAI or Anthropic shape. That is clear enough to differentiate it from report/chart tools in the namespace, but it never names the closest sibling (astroway_mcp_tools_list) or explains the distinction, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance and no stated alternative. The mention of `format=openai` as the default is parameter behavior, not a usage rule, and the agent is left to infer whether this is for building an agent, curated retrieval, or an MCP tool listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the credit cost of one or more endpoints WITHOUT invoking them. Returns total + per-endpoint breakdown with tier annotations. Useful when planning multi-step workflows: estimate first, ask user confirmation, then invoke. Cache TTL 5 min.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoints | Yes | Endpoint paths to estimate, e.g. ["/chart", "/synastry", "/reports/natal"]. Leading slash optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety bar is low; the description still adds real value by clarifying that endpoints are NOT invoked and that results are cached with a 5-minute TTL. It also discloses the return shape (total + per-endpoint breakdown with tier annotations), which is meaningful since no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core capability and the non-invocation guarantee, followed by workflow guidance and the cache note. Nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explains the return value, and the invocation-free and cache behaviors are covered. For a one-parameter, read-only estimator this is fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'endpoints' parameter is fully documented with examples and the leading-slash rule in the schema. The description only restates 'one or more endpoints' without adding format or constraint detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Estimate the credit cost of one or more endpoints') and immediately pins the scope with 'WITHOUT invoking them', which no sibling tool does. An agent can distinguish this from the many invocation/report siblings at a glance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit workflow guidance: 'estimate first, ask user confirmation, then invoke' for multi-step planning. This is clear when-to-use context, though it names no alternative tool or when-not-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
2 personas debate a topic, multi-round transcript.
[Group: MCP Advanced] [Cost: 100 credits (Tier 4)]
| Name | Required | Description | Default |
|---|---|---|---|
| chart | No | 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. | |
| topic | Yes | ||
| agentA | Yes | ||
| agentB | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| rounds | No | ||
| language | No | en | |
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. |
| Name | Required | Description |
|---|---|---|
| transcript | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent and non-destructive behaviour, so the safety bar is low. The description adds genuinely useful operational facts the annotations do not carry: the tool is an MCP Advanced feature costing 100 credits (Tier 4). It still says nothing about how rounds affect runtime or output, or whether chart context is mandatory for a meaningful debate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short lines, front-loaded with the core purpose followed by group and cost metadata; there is no filler or repetition. The brevity is somewhat a result of under-specification rather than disciplined editing, but structurally it is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool: 8 parameters, a nested chart object with detailed validation rules, and an output schema. The description covers none of that complexity and omits the astrological framing entirely, leaving an agent to infer from the schema alone what inputs matter. Output format is covered by the output schema, so that omission is acceptable, but the rest is a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 38% and several parameters (topic, agentA, agentB, rounds, language) carry no schema description, so the description is expected to compensate — and it does not, adding no parameter meaning whatsoever. 'multi-round' only obliquely hints at the rounds parameter, and nothing explains what agentA/agentB strings should contain or how chart is consumed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete verb and output ('2 personas debate a topic, multi-round transcript'), so an agent knows this produces a debate transcript rather than a single answer. However, it never differentiates itself from near-neighbours like astroway_mcp_ai_chat or astroway_mcp_multi_agent_coordinate, and it omits that the debate is anchored to an astrological chart, which the schema makes clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance at all: no statement of what situation calls for a two-persona debate over a single-shot chat, no prerequisites, and no mention of alternatives. The only extra text is group and cost metadata, which is billing context rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
8 personas with specialties.
[Group: MCP Advanced] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| count | No | |
| personas | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely new context by disclosing a 10-credit Tier 1 cost, but omits what the status payload represents or whether it reflects live pool state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is very short and front-loads the one substantive fact, but the first sentence is a dangling fragment rather than a complete statement of purpose, and the bracket tags read as metadata padding rather than description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, and annotations cover safety, so the description's remaining burden is small. It is still thin on what 'pool status' reports and when it should be invoked, leaving a minor gap for a zero-required-parameter status tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both optional compaction parameters (fields, precision) are thoroughly documented in the schema with examples. The description adds nothing about parameters, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '8 personas with specialties' is a noun fragment that hints at the returned content but never states what the tool does or what 'pool status' means. It does not distinguish this from siblings like astroway_agent_tools or astroway_mcp_tools_list, which also concern agent/persona inventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no indication of when to call this versus the many sibling agent/tools-listing tools, and no prerequisites or exclusions. The only guidance offered is the cost tag '[Cost: 10 credits (Tier 1)]', which helps budget decisions but says nothing about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Chat answered from the positions we computed for this birth moment, not from the model's memory of a sun sign. Carries up to 10 turns of history, replies in 21 languages, and takes four voices through persona. Send your own provider key and the turn costs 5 credits instead of the endpoint price.
[Group: AI & MCP] [Cost: 100 credits (Tier 4)]
| Name | Required | Description | Default |
|---|---|---|---|
| chart | No | 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. | |
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| history | No | ||
| message | Yes | ||
| persona | No | astrologer | |
| language | No | uk | |
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. |
| Name | Required | Description |
|---|---|---|
| model | No | |
| reply | No | |
| tokens | No | |
| persona | No | |
| language | No | |
| disclaimer | No | |
| duration_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnly, non-destructive, openWorld, non-idempotent), and the description usefully adds context beyond that: a 10-turn history cap, 21 supported languages, four persona voices, and a cost behavior where sending your own provider key drops the turn to 5 credits. It stops short of describing failure modes or what the chart object must contain to succeed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core differentiator ('answered from the positions we computed') before secondary facts about history, languages, and pricing. The trailing group/cost tags are metadata rather than prose, so there is minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 covers the AI-behavioral surface (grounding, history, language, persona, cost). For a 7-parameter tool with nested objects and low schema coverage, it could say more about the chart input contract, but the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, so the description should compensate, and it partly does by explaining history (10 turns), language (21), and persona (four voices). However, it says nothing about the required `message`, the complex nested `chart`, or the compact-mode `fields`/`precision` parameters, leaving those to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — a chat grounded in computed chart positions rather than the model's sun-sign memory — which is clearly distinguishable from report-generation siblings. It does not explicitly name an alternative among the many AI siblings (explain_aspect, explain_transit, comparison_coach), so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool is but never says when to reach for it versus the other AI siblings or the narrative-report tools. No prerequisites or selection conditions are given; the agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Coach two charts on relationship dynamics.
[Group: AI & MCP] [Cost: 100 credits (Tier 4)]
| Name | Required | Description | Default |
|---|---|---|---|
| chart1 | Yes | 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. | |
| chart2 | Yes | 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. | |
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| language | No | uk | |
| question | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. |
| Name | Required | Description |
|---|---|---|
| coaching | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare a safe read-only, non-destructive, open-world operation. The description adds useful cost context (100 credits, Tier 4) and group membership, but does not disclose rate limits, auth requirements, or what the AI coach actually returns. With annotations covering safety, this partial extra context merits a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with cost and group metadata placed clearly after the core sentence. It wastes no words, although it is arguably too sparse for a tool of this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with nested chart objects and multiple AI/synastry siblings, the description is far too thin. The output schema covers return values, but the description does not explain what 'coaching' entails or when to select this tool over alternatives, leaving a substantial contextual gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, and the description adds no parameter-level meaning beyond the schema. It says 'two charts' but does not clarify the role of the required question field, language, precision, or fields parameters, nor does it help compensate for the less-documented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (two charts) and domain (relationship dynamics), but the verb 'Coach' is vague about what the tool actually produces. It does not distinguish this from sibling reports like astroway_reports_ai_synastry_narrative, leaving an agent unsure whether this is an interactive coaching session, a report, or something else.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description does not mention when this tool should be chosen over similar two-chart tools such as synastry reports or multi-chart context, nor are any preconditions or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detailed explanation of an aspect between two planets.
[Group: AI & MCP] [Cost: 100 credits (Tier 4)]
| Name | Required | Description | Default |
|---|---|---|---|
| chart | No | 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. | |
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| planet1 | Yes | ||
| planet2 | Yes | ||
| language | No | uk | |
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| aspectType | Yes |
| Name | Required | Description |
|---|---|---|
| explanation | No |
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's only added behavioral fact is the cost (100 credits, Tier 4), which is genuinely useful for an agent budgeting calls, but nothing is said about latency, auth, or output shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and front-loaded, but the terseness here reflects under-specification rather than efficient communication. The metadata lines consume half the length without adding invocation help.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no prose, but the description leaves key input questions open: how planets must be named, which chart object is required for a natal calculation, and what the aspectType enum means in context. For a 7-parameter tool with a nested birth-data object, this is thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, and the undescribed parameters include the three required ones (planet1, planet2, aspectType). The phrase 'between two planets' loosely implies planet1/planet2 but gives no naming convention or accepted values, and aspectType, language, fields and precision get nothing despite the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: an explanation of an aspect between two planets. An agent can tell what it does, though it never contrasts itself with the sibling astroway_mcp_ai_explain_transit, which is the nearest alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as explain_transit or the report tools. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a current transit hitting your natal chart.
[Group: AI & MCP] [Cost: 100 credits (Tier 4)]
| Name | Required | Description | Default |
|---|---|---|---|
| chart | Yes | 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. | |
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| language | No | uk | |
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| aspectType | Yes | ||
| natalPlanet | Yes | ||
| transitDate | Yes | ||
| transitPlanet | Yes |
| Name | Required | Description |
|---|---|---|
| explanation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false, openWorldHint=true and idempotentHint=false. The description adds genuinely useful operational context by disclosing the cost (100 credits, Tier 4) and the AI grouping, which helps an agent budget. It does not explain the non-idempotent nature of an AI-generated explanation or any latency/rate behavior, so it adds some but not rich value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence carries the core purpose, with the group and cost tags kept as structured metadata rather than prose. It is tight and waste-free, though its brevity edges into under-specification rather than model conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with a nested chart object and five required fields, the description omits routing guidance against several plausible siblings and says nothing about the transit inputs. The presence of an output schema excuses it from describing return values, but the selection and input story is still incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 38% and the five required parameters (chart, transitDate, transitPlanet, natalPlanet, aspectType) carry no schema descriptions at all. The description only obliquely implies a transit/natal pairing and says nothing about expected values or formats for those required fields, so it does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Explain' applied to 'a current transit hitting your natal chart.' An agent can tell what the tool produces. It stops short of distinguishing itself from close siblings such as astroway_mcp_ai_explain_aspect or astroway_reports_ai_transit_narrative, so it is clear but not sibling-differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use, when-not-to-use, or named alternative. The sentence implies the context (a transit to your natal chart) but gives no condition that would route an agent here instead of the aspect explainer or the transit narrative report. This matches the 'no guidance' band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run N personas in parallel + LLM synthesis.
[Group: MCP Advanced] [Cost: 100 credits (Tier 4)]
| Name | Required | Description | Default |
|---|---|---|---|
| chart | No | 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. | |
| agents | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| language | No | en | |
| question | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. |
| Name | Required | Description |
|---|---|---|
| synthesis | No | |
| individual | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description only needs to add context. It does add parallel execution and a 100-credit Tier 4 cost, which is useful. However, it omits latency implications from LLM synthesis, auth requirements, and any detail about valid agent choices.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is very short and front-loads the core action before the group and cost tags. No sentence is wasted, though the brevity reflects under-specification rather than thorough contextual completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with a nested chart object, six parameters, required agent and question fields, and many sibling tools. The description explains almost none of that beyond a two-line summary and cost, leaving significant gaps even though an output schema exists for return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description adds no parameter-level meaning for question, agents, chart, fields, language, or precision. In particular, the required 'agents' array and its 2-4 item constraint, as well as how 'chart' relates to the question, are left entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a high-level verb and resource ('Run N personas in parallel + LLM synthesis') but does not define what a persona is, what is being coordinated, or how this differs from siblings such as astroway_mcp_agent_debate. The [Group] and [Cost] tags are metadata rather than purpose clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use, when-not-to-use, or alternative-tool guidance. The closest sibling, astroway_mcp_agent_debate, is not mentioned, and the cost tier alone does not tell an agent when this tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compact context for MCP agents working across multiple charts.
[Group: AI & MCP] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| charts | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| intent | No | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. |
| Name | Required | Description |
|---|---|---|
| notes | No | |
| intent | No | |
| summaries | No | |
| chartCount | No | |
| contextHash | No | |
| summaryString | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered elsewhere. The description adds only the cost tag (10 credits, Tier 1); it says nothing about batch limits, what the compact response excludes, or the idempotentHint=false implication that repeated calls may vary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence plus metadata tags are front-loaded and free of padding, so it is structurally clean. However, the brevity here is under-specification rather than conciseness: the sentence carries almost no callable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 described, but for a tool with an enum-driven intent, a compact-mode fields selector and a 6-item batch cap, the description omits nearly everything an agent needs to choose and configure it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, so the description is expected to compensate — and it does not. The compact-mode controls (fields, precision) and the intent enum are never mentioned in the description, leaving the agent to discover their meaning entirely from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Compact context for MCP agents working across multiple charts" restates the tool name (multi-chart context) without a concrete verb or resource for what is actually produced. It never says it computes natal chart data for multiple subjects, nor does it distinguish this tool from sibling report/chart tools like astroway_reports_natal or astroway_reports_synastry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage signal is the implied "working across multiple charts," from which an agent might infer batch multi-subject use. There is no explicit when-to-use, no exclusions, and no mention of when a single-chart or report sibling is preferable, despite ~40 alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword-tag scoring over chart chunks.
[Group: MCP Advanced] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| topK | No | ||
| chart | Yes | 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. | |
| query | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. |
| Name | Required | Description |
|---|---|---|
| query | No | |
| total | No | |
| tokens | No | |
| matches | No | |
| results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this as a read-only, idempotent, closed-world, non-destructive operation. The description adds cost and group context, which is useful, but does not disclose any operational behavior such as result format, ranking details, or rate-limit implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is very short and front-loads the core phrase before the bracketed metadata. There is no wasted prose, though the concision contributes to the broader underspecification problem rather than being a structural flaw itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool takes five parameters including a nested chart object, exists among many siblings, and has an output schema. Despite that complexity, the description does not explain selection criteria, query semantics, or how this differs from report-generation tools, leaving it materially incomplete for agent routing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is moderate at 60%, and the description adds no parameter meaning at all. It does not clarify what 'query' should contain, how 'topK' affects results, or how 'chart' is used, so key semantics remain dependent on the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Keyword-tag scoring over chart chunks,' which reveals the mechanism and resource type, but it never states the core action as a verb such as 'search' and does not distinguish this tool from the many sibling retrieval/report tools. An agent can infer it is a retrieval tool, but the purpose remains vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, no prerequisites, and no alternatives to consider. It only supplies group and cost metadata, leaving the agent with no routing signal among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Server-Sent Events streaming chat completion with optional chart context.
[Group: AI & MCP] [Cost: 100 credits (Tier 4)]
| Name | Required | Description | Default |
|---|---|---|---|
| chart | No | 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. | |
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| message | Yes | ||
| language | No | uk | |
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, open-world, non-idempotent). The description adds two genuinely useful behavioral facts beyond them: the response arrives as Server-Sent Events, and each call costs 100 credits (Tier 4). It says nothing about auth requirements, rate limits, or what the stream events look like, so it is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence that states the core capability, followed by two bracketed metadata tags. Very tight, though the group/cost tags sit after the payload rather than being folded in naturally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with a nested birth-chart object, no output schema, and only 60% schema description coverage, the definition is thin. It does not describe the streamed response shape, streaming lifecycle, or the required message parameter, and gives no guidance on how chart context should be formed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60% and the nested chart object carries extensive inline documentation that the description does not repeat. The 'optional chart context' phrase confirms the chart parameter exists but adds no semantics for message, language, fields, or precision, so it does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: an SSE streaming chat completion, with the chart-context option noted. It is clearer than a bare 'chat', but it never distinguishes itself from sibling astroway_mcp_ai_chat (presumably the non-streaming counterpart) or astroway_mcp_tool_call_stream, so the agent must guess which chat entry point to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, or alternative guidance is given. The description notes that chart context is optional but never says when you should supply it or how it changes the answer, and it never mentions the sibling chat tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SSE-stream of a tool call envelope.
[Group: MCP Advanced] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| tool | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| language | No | en | |
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered without the description. The description does add one genuinely useful behavioral fact not in annotations: the 10-credit Tier 1 cost. However, for a streaming tool it says nothing about stream termination, error semantics, or partial delivery, which is the behavior an agent most needs here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and the core statement is front-loaded, so nothing is wasted. But the two bracketed metadata lines are boilerplate and the resulting length is too thin for the tool's complexity, so brevity here reads as under-specification rather than tightness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters (including a nested arbitrary 'args' object), no output schema, and an opaque streaming return, the definition is far too thin: it never explains what the streamed envelope contains, how the stream ends, or how 'args' maps to the target tool. An agent must guess at most of the call contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%: 'tool' (the sole required parameter) and 'args' carry no description, and 'language' has only an enum. The description supplies zero parameter guidance, so it fails to compensate for the coverage gap on a 5-parameter tool with a nested free-form object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It pairs a specific verb ('SSE-stream') with a resource ('tool call envelope'), which is more than a tautology, but 'tool call envelope' is unexplained jargon and the definition does nothing to separate it from close siblings like astroway_mcp_streaming or astroway_mcp_tools_list. An agent cannot tell from this text which one to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool, when not to, or what alternative exists for the same need. The only context is the group/cost tag, which tells the agent a price but not a use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-generated tool manifest for MCP clients (modelcontextprotocol/2025-03 spec).
[Group: AI & MCP] [Cost: see your plan — endpoint not in the public credit manifest]
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. |
| Name | Required | Description |
|---|---|---|
| spec | No | |
| notes | No | |
| tools | No | |
| server | No | |
| toolCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds a spec version and notes that cost is not in the public credit manifest, which is useful behavioral context. However, it does not explain what the manifest contains, how it is scoped, or any other operational behavior beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads its main claim about being an auto-generated manifest. The bracketed group and cost lines add metadata without excessive verbosity. It is efficient, though the bracket metadata is only marginally useful for tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and the input schema is fully documented, so return values and parameters do not need explanation in the description. However, the description remains thin on purpose and usage guidance, making it only minimally complete for an agent deciding whether to call this tool. The low complexity of the tool keeps it from being inadequate, but notable gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (fields and precision) are already fully documented in the schema. The description adds no parameter-level meaning beyond what is in the input schema. With complete schema coverage and no additional description detail, a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says it is an auto-generated tool manifest for MCP clients, which identifies the general resource but uses no action verb and does not explicitly state that it lists available MCP tools. It also does not distinguish this tool from nearby siblings such as astroway_agent_tools or the MCP-related tools. Purpose is therefore implied rather than clearly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage context is the phrase 'for MCP clients,' which implies an audience but gives no guidance on when to call this tool versus alternatives. It does not mention prerequisites, exclusions, or sibling tools. This is the same level as a definition that provides only an implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Arroyo's evolutionary cycle.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
(Cursor-friendly alias for astroway_psychological_modern_arroyo_cycle_of_becoming.)
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| source | No | |
| doctrine | No | |
| fullCycle | No | |
| currentAge | No | |
| disclaimer | No | |
| currentPhase | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description usefully adds the credit cost (10, Tier 1) and the alias relationship, which annotations do not convey. It says nothing about output characteristics, though the output schema exists to carry that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and front-loaded, but the brevity reflects under-specification rather than discipline. The bracketed metadata lines (group, cost, alias) are the only structured content, and the one prose sentence is too thin to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter charting tool with only 33% schema coverage, the description is far too thin; the presence of an output schema excuses it from explaining return values, but nothing covers purpose, usage, or the undocumented parameters. An agent cannot confidently select or configure this tool from the definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% across 15 parameters, so the description carries a heavy compensation burden — and it supplies none, mentioning no parameter at all. Several params (fields, timezone, precision, timezoneOffset) are self-documented in the schema, but required params like date/time/latitude/longitude and enums like houseSystem/zodiacType remain unexplained in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description reduces to "Arroyo's evolutionary cycle," which essentially restates the title "Arroyo: Cycle of Becoming" without naming a verb or saying what is computed or returned. It does not distinguish this tool from the many sibling psychological/astrology tools (element_balance, cycles_of_becoming, etc.). The only concrete routing information is that it is a Cursor-friendly alias of another tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus its alias twin `astroway_psychological_modern_arroyo_cycle_of_becoming` or the sibling psychological analyses. The group label and cost tier are metadata, not usage guidance. An agent is left to infer the selection criteria entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Element distribution and integration.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
(Cursor-friendly alias for astroway_psychological_modern_arroyo_element_balance.)
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| counts | No | |
| source | No | |
| doctrine | No | |
| disclaimer | No | |
| dominantElement | No | |
| deficientElement | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful non-schema context — the 10-credit Tier 1 cost and the alias relationship — but says nothing about what the analysis computes or what constraints apply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is short and front-loads the one substantive phrase; the bracketed group/cost/alias lines are compact and each carries information. Nothing is padded, though the metadata blocks crowd out any real functional content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 described, but for a 15-parameter chart-calculation tool with low schema coverage the description omits everything an agent needs: what an element balance report contains, how it differs from the integration sibling, and how the required date/time/coordinate inputs drive the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 15 parameters and only 33% schema description coverage, the description carries a heavy compensating burden and supplies nothing — no explanation of date/time/latitude/longitude requirements, timezone handling, or the compact-mode fields parameter. The undefined parameters (city, name, cosmogram, zodiacType, houseSystem, ayanamsaId, etc.) are undocumented in both places.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Element distribution and integration" largely restates the name and title ("Element Balance") rather than naming a specific operation, input, or output. It gives no verb (compute/generate/analyze) and no mention of a natal chart, so an agent cannot distinguish it from the sibling astroway_psya_element_integration or relational_element_map.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus the many sibling psychological/Arroyo tools, nor any prerequisites or exclusions. The only routing hint is that it is a 'cursor-friendly alias' for astroway_psychological_modern_arroyo_element_balance, which helps deduplicate but does not explain when this analysis is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Strategies for integrating weak elements.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
(Cursor-friendly alias for astroway_psychological_modern_arroyo_element_integration.)
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| counts | No | |
| source | No | |
| doctrine | No | |
| disclaimer | No | |
| recommendations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the credit cost (10 credits, Tier 1) and group classification, which is genuinely useful for invocation budgeting, but says nothing about the return format or interpretation depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and front-loaded, with the purpose statement first. The bracketed metadata is slightly noisy but the overall footprint is tight and nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter tool the description is too thin: it omits what is returned, how the 'weak elements' are determined, and whether required date/time/lat/long drive a chart calculation. The output schema and annotations offset this somewhat, but the description itself leaves major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 15 parameters and only 33% schema description coverage, several inputs (city, name, cosmogram, zodiacType, houseSystem, ayanamsaId) are undocumented in both schema and description. The description contributes no parameter meaning at all, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific output ('strategies for integrating weak elements'), which is more than a restatement of the title, but it never says what the tool actually computes or returns, and it does not distinguish itself from close siblings like element_balance or relational_element_map.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of any alternative tool. The agent is left to infer that this is a psychological-interpretation tool rather than a chart calculator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Relational element compatibility map.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
(Cursor-friendly alias for astroway_psychological_modern_arroyo_relational_element_map.)
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| source | No | |
| doctrine | No | |
| disclaimer | No | |
| synergyWith | No | |
| tensionWith | No | |
| yourDominant | No | |
| partnerSeeking | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds genuinely useful non-schema context: the 10-credit Tier 1 cost and the fact that this is a cursor-friendly alias for the canonical tool. It says nothing, however, about what the map contains or how it is computed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and front-loads the purpose line, but the brevity reflects under-specification rather than tight editing — the group, cost, and alias tags are metadata fragments rather than substantive guidance. Nothing is wasted, but very little is said.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter chart tool with only 33% parameter coverage, the description is far too thin: no statement of what the compatibility map contains, no guidance on required birth data, and no differentiation from sibling element tools. The existence of an output schema excuses it from describing return values, but the input-side and purpose-side gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 15 parameters and only 33% schema description coverage, the description carries a heavy burden and contributes nothing — no mention of date, time, latitude/longitude, zodiac type, ayanamsa, or house system semantics. The undocumented parameters (city, date, name, time, cosmogram, zodiacType, houseSystem, ayanamsaId, latitude, longitude) are left to bare types and enums, which the description does not compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a resource ('relational element compatibility map') but as a bare noun phrase with no verb, so what the tool actually computes is left implicit. It does not distinguish itself from the many closely named siblings (element_balance, element_integration, cycle_of_becoming), all of which are 'Modern Psychological' tools. A reader can guess the domain but not the specific operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the element/relational siblings. The only context given is the group tag and credit cost, which is billing metadata rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Water-house trauma patterns.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
(Cursor-friendly alias for astroway_psychological_modern_arroyo_water_houses_trauma.)
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| source | No | |
| doctrine | No | |
| h4_roots | No | |
| h8_shared | No | |
| disclaimer | No | |
| h12_unconscious | No | |
| totalPlanetsInWater | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds cost tier (10 credits) which is useful, but says nothing about what the tool computes, what inputs it needs, or what the output contains – minimal added behavioral context for a chart-analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and front-loaded, but the content is mostly metadata (group, cost, alias). It is concise without being informative, so it neither wastes much space nor earns it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter chart tool with an output schema, the description should at least say what it computes and how it relates to its alias target. It relies almost entirely on the schema and annotations, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% across 15 parameters, yet the description explains none of them. Required birth-data params (date, time, latitude, longitude) and options like ayanamsa, houseSystem, fields, and timezone are left entirely to the schema, which itself documents only some.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Water-house trauma patterns', which restates the title/name rather than defining what the tool computes or returns. It does not distinguish it from siblings like astroway_psychological_modern_arroyo_water_houses_trauma (of which it is stated to be an alias) nor from the other Arroyo tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, or alternatives guidance is given. The only routing information is 'cursor-friendly alias for X', which tells nothing about selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Arroyo's evolutionary cycle.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| source | No | |
| doctrine | No | |
| fullCycle | No | |
| currentAge | No | |
| disclaimer | No | |
| currentPhase | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds only the credit cost (10 credits, Tier 1), which is mildly useful, but says nothing about what the computation actually yields or any constraints on core required inputs like date/time/lat/long.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two fragments, no waste in the literal sense, but also no substance — this is under-specification rather than conciseness. The credit/group metadata is front-loaded while purpose is absent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter astrological computation with a required date/time/latitude/longitude core, the description omits what the tool produces and how it differs from its many siblings. An output schema reduces the need to document returns, but nothing here addresses invocation or selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% across 15 parameters, so the description is obligated to compensate and does not — it mentions no parameter at all. Fields like ayanamsaId, cosmogram, zodiacType, houseSystem, and name/city defaults are left to the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the title ('Arroyo's evolutionary cycle' vs 'Arroyo: Cycle of Becoming') without a specific verb or resource. It never says what the tool computes or returns, so an agent cannot distinguish it from the many sibling cycle-of-becoming tools (rudhyar_cycles_of_becoming, psya_cycle_of_becoming).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no exclusions, and no mention of the competing siblings despite a large cluster of near-identical tools. The only added information is a group label and a credit cost, neither of which helps selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Element distribution and integration.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| counts | No | |
| source | No | |
| doctrine | No | |
| disclaimer | No | |
| dominantElement | No | |
| deficientElement | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds the cost tier ('10 credits, Tier 1'), which is genuinely useful pre-invocation context, but says nothing about what the result contains or how it is scoped.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and free of padding, but the brevity comes from under-specification rather than efficiency: the two lines carry no operational content beyond group and price metadata. Front-loading is moot when there is almost nothing to front-load.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter astrological computation with an output schema and a large family of near-identical siblings, the description leaves the agent unable to distinguish this tool's output from element_integration or the psya/psyg variants. The output schema excuses it from describing return values, but nothing else is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 15 parameters and only 33% schema description coverage, the description is expected to compensate and does not — it mentions no parameters at all. A handful of the undocumented params (date, time, latitude, longitude, city) are self-evident from name and type, which keeps this above a 1, but the sidereal/house-system options receive no framing from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a restatement of the title 'Arroyo: Element Balance' in other words ('Element distribution and integration'), with no verb, no statement of what artifact is produced, and no differentiation from the many sibling element tools (astroway_psya_element_balance, astroway_psychological_modern_arroyo_element_integration). An agent cannot tell what this computes or how it differs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance at all: no prerequisites, no conditions, and no routing to alternatives such as the element_integration or relational_element_map siblings that clearly overlap. The only contextual signal is the '[Group: Modern Psychological]' tag, which is not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Strategies for integrating weak elements.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| counts | No | |
| source | No | |
| doctrine | No | |
| disclaimer | No | |
| recommendations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds the 10-credit Tier 1 cost, which is genuinely useful behavioral information for a paid call, but says nothing about what the tool computes or what conditions affect the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely tight: one topical sentence plus bracketed metadata, with no filler or repetition. It is front-loaded and scannable, though the brevity comes at the cost of substance rather than being an efficient summary of a complete definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter astrology tool with only 33% schema coverage, the description is far too thin. An output schema exists, so return values need not be explained, but the agent still lacks any indication of required inputs, the sidereal/tropical choice, or how this differs from sibling element tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% across 15 parameters, so the schema cannot carry the burden and the description must compensate — yet it mentions no parameter at all. It never hints at the required birth data (date, time, latitude, longitude) or the meaning of ayanamsa, zodiacType, houseSystem, or fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Strategies for integrating weak elements' states the topical output but supplies no verb — it never says it generates/analyzes a chart or produces a report. It also fails to distinguish itself from the near-identical sibling astroway_psychological_modern_arroyo_element_balance. An agent knows the theme but not the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of the closely related element_balance or cycle_of_becoming siblings. The only context is metadata tags for group and credit cost, which do not help an agent choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Relational element compatibility map.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| source | No | |
| doctrine | No | |
| disclaimer | No | |
| synergyWith | No | |
| tensionWith | No | |
| yourDominant | No | |
| partnerSeeking | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered structurally. The description adds only a cost note and nothing about auth, computation semantics, or what 'compatibility' means here, so it contributes almost no behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and front-loads a fragment, but the brevity comes from under-specification rather than precision. The bracket metadata lines occupy most of the content while the actual purpose goes unstated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 described, but for a 15-parameter astronomy/psychology tool with opaque enums and no sibling differentiation, this description is far too thin to let an agent invoke it correctly. It omits prerequisites, output shape hints, and any distinction from the many parallel relational/element tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 15 parameters, only ~33% schema description coverage, and cryptic enum values (houseSystem codes P/K/R/C/W..., ayanamsaId as an undocumented number|null), the description is the place to compensate but says nothing about any parameter. Required inputs date/time/latitude/longitude and the meaning of 'fields' compact mode are left entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description reduces to 'Relational element compatibility map,' which essentially restates the title 'Arroyo: Relational Map' without a verb or any statement of what is actually computed or returned. It does not distinguish this tool from its near-identical siblings, notably astroway_psya_relational_element_map and astroway_psychological_modern_arroyo_element_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, when not to, or which sibling to prefer. The only extra content is group/cost metadata ('10 credits (Tier 1)'), which is pricing, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Water-house trauma patterns.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| source | No | |
| doctrine | No | |
| h4_roots | No | |
| h8_shared | No | |
| disclaimer | No | |
| h12_unconscious | No | |
| totalPlanetsInWater | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's one genuine addition is the cost disclosure (10 credits, Tier 1), which is useful for an agent budgeting calls, but it says nothing about methodology, latency, or what the analysis produces beyond what the output schema already provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single content sentence is front-loaded, but this is under-specification rather than conciseness. Two of the three lines are bracketed administrative metadata, so effectively no substantive text was written for a 15-parameter analysis tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, but for a specialized psychological-astrology technique with 15 inputs and low schema coverage the definition is far too thin. Nothing tells the agent what 'Arroyo water-house trauma' means, when it applies, or how it differs from the sibling psya variant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 15 parameters and only 33% schema description coverage, the description must compensate for undocumented fields such as city, date, time, name, latitude, longitude, cosmogram, zodiacType, houseSystem and ayanamsaId — and it compensates for none of them. The required four are self-explanatory by name and pattern, which keeps this above the floor, but the description adds zero semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Water-house trauma patterns' is essentially a restatement of the title 'Arroyo: Water Houses Trauma' with no verb and no statement of what is actually computed or returned. It gives no way to distinguish this tool from the near-identical sibling astroway_psya_water_houses_trauma. It is tautological rather than informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The sibling list contains an almost duplicate (astroway_psya_water_houses_trauma) plus four other Arroyo-family tools, and the description offers nothing to help an agent choose between them. The [Group] and [Cost] lines are metadata, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Archetypal patterns in the chart per Liz Greene.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| source | No | |
| figures | No | |
| doctrine | No | |
| disclaimer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description's only added behavioral fact is the cost (10 credits, Tier 1), which is genuinely useful but thin; it says nothing about computation time, whether the whole-chart is required, or caching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler, and the metadata tags are compact. It is efficient, though arguably under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 annotations cover the safety profile. What remains missing is enough context to route correctly among the many Greene/Psychological siblings, which is the main incompleteness for a 15-parameter report tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% across 15 parameters, so the description carries a real burden to clarify inputs. It adds nothing about date/time/lat/long requirements or the sidereal/house-system options, leaving several parameters undocumented in both places.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a resource ('archetypal patterns in the chart') and a framework author ('per Liz Greene'), so the general purpose is inferable. However, it does not specify what an 'archetypal figure' result actually contains, and it offers no differentiation from the many sibling Greene tools (individuation_path, lunar_myth, parental_imagos, saturn_shadow) or the nearly identically named astroway_psyg_archetypal_figures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the sibling psychological/archetypal tools. The group and cost tags are metadata, not usage direction, so an agent must guess from the name alone which of the ~40 siblings to select.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Individuation arc per natal chart.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| source | No | |
| keyAges | No | |
| doctrine | No | |
| disclaimer | No | |
| individuationMarkers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety traits (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false), so the description does not need to restate them. It adds useful context in the form of cost (10 credits, Tier 1) and group classification, but says nothing about computation behavior, permissions, or output characteristics beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: a one-line purpose followed by structured group and cost metadata. It contains no filler, though its brevity is partly the cause of the missing guidance rather than pure efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter astrological calculation with low schema description coverage and many sibling tools, the description is incomplete. Output schema and annotations reduce the burden, but selection guidance and parameter context are still missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 15 parameters and only 33% schema description coverage, the description is expected to compensate but provides zero parameter meaning. It does not mention required inputs, defaults, enums, or the special compact modes, leaving most parameter semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific astrological resource (Individuation arc per natal chart), but it is a noun phrase rather than a clear action and does not distinguish this tool from similar siblings such as astroway_psyg_individuation_path or other Greene psychological tools. It is not a tautology, but it leaves the agent guessing what operation is performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 guidance, and no named alternative among the many sibling tools. The group and cost metadata do not tell the agent when this individuation path tool should be selected over related psychological or astrological tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lunar archetypes by sign and house.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| moon | No | |
| theme | No | |
| shadow | No | |
| source | No | |
| doctrine | No | |
| disclaimer | No | |
| mythicFigure | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the credit cost and tier, which is genuinely useful non-annotation context, but says nothing about output shape or behavioral limits; with annotations carrying the safety burden a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first sentence and the metadata tags are compact. It is efficiently sized, though its brevity is closer to under-specification than to disciplined concision given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, but for a 15-parameter tool with 33% schema coverage and a very close sibling the description omits required-input context, usage conditions and sibling differentiation. It is not complete enough for an agent to call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% across 15 parameters, so the description is expected to compensate and it does not - it never mentions date, time, latitude, longitude, houseSystem, zodiacType or any other input. Several parameters are documented only inside the schema, leaving the rest undocumented in both places.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource and scope ('Lunar archetypes by sign and house'), so an agent knows roughly what it produces. However it uses a noun phrase with no verb and gives no differentiation from the near-identical sibling astroway_psyg_lunar_myth, so the boundary between them is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only non-descriptive content is the group tag '[Group: Modern Psychological]' and cost '[Cost: 10 credits (Tier 1)]'. There is no statement of when to prefer this tool over astroway_psyg_lunar_myth or the other psychological-modern siblings, and no prerequisites or input expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parental imagos analysis.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| source | No | |
| doctrine | No | |
| disclaimer | No | |
| shadowMarkers | No | |
| exteriorParent | No | |
| interiorParent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description usefully adds the group and the cost (10 credits, Tier 1), which is real behavioral context an agent may need for budgeting. It does not, however, disclose what inputs drive the analysis or what the result contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short and front-loaded, with no filler sentences. However, it is minimal by under-specification rather than by disciplined editing, and the bracketed metadata lines carry more weight than the actual purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not required. But for a 15-parameter analysis tool with only 33% schema coverage and no behavioral or usage detail, the description leaves the agent without enough to invoke it confidently or distinguish it from its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% across 15 parameters, so the description must compensate and it adds nothing at all. Required fields (date, time, latitude, longitude) and the several undocumented enum/boolean params (cosmogram, ayanamsaId, zodiacType, houseSystem) get no clarification. This is a clear gap given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Parental imagos analysis" essentially restates the title/name (Greene: Parental Imagos) without stating what the analysis actually computes or returns. It provides no verb+resource distinction from the sibling astroway_psyg_parental_imagos, which appears to be the same concept under a different prefix. An agent cannot tell what this produces versus its neighbors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use, when-not-to-use, or alternative guidance anywhere in the description. The presence of a near-identical sibling (astroway_psyg_parental_imagos) makes routing guidance especially valuable, and none is given. The only orientation is the bracketed group and cost tags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Saturn-as-shadow integration work.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| saturn | No | |
| source | No | |
| doctrine | No | |
| disclaimer | No | |
| shadowTheme | No | |
| integrationPrompt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, closed-world, non-destructive behavior, so the safety profile is covered. The only added trait is the cost tag (10 credits, Tier 1), which is genuinely useful, but nothing is said about what the computation requires, whether the four required birth-data inputs are mandatory, or how heavy the operation is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short lines plus bracketed metadata tags — nothing is padded or repeated, and the purpose statement leads. However, the brevity reflects under-specification rather than disciplined conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter, 10-credit psychological report tool, the definition is far too thin. An output schema exists, so return values need not be described, but the description never conveys what the Saturn-shadow analysis contains or what makes the required birth data meaningful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% across 15 parameters, so the description is expected to compensate — and it contributes nothing about any parameter. The schema does richly document a few key fields (fields, ayanamsa, timezone, precision, timezoneOffset), which keeps this above the floor, but city, cosmogram, zodiacType, and the four coordinate/date inputs remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Saturn-as-shadow integration work" largely restates the tool's own title ("Greene: Saturn Shadow") without a concrete verb or resource. It gives no indication of what is actually produced (a report? a chart? an interpretation?) and offers nothing to distinguish it from the near-identical sibling astroway_psyg_saturn_shadow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no routing to alternatives. With a sibling named astroway_psyg_saturn_shadow sitting directly in the same family, the omission is especially costly — an agent has no basis to choose between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Outer-planet cycles as becoming.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| cycles | No | |
| source | No | |
| doctrine | No | |
| currentAge | No | |
| disclaimer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds operational context not present in structured data — the group and the 10-credit (Tier 1) cost — which is genuinely useful, but it says nothing about what the analysis returns or any computation-specific behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and front-loaded, but the brevity comes from under-specification rather than economy. The one substantive sentence conveys almost no information, so the size does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter chart tool with an output schema and many close siblings, the description is far too thin: it never says what cycles are computed, what the output represents, or how to choose it over the other cycle-of-becoming tools. The output schema relieves it of explaining return values, but the selection and semantics gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% across 15 parameters, so the description is expected to compensate, and it contributes nothing about any parameter. Required birth-data fields are self-explanatory by name, but undocumented options like zodiacType, houseSystem, and cosmogram get no help from either source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase "Outer-planet cycles as becoming" is a fragment that largely restates the title "Rudhyar: Cycles of Becoming" and adds only the vague qualifier "outer-planet." It does not state what the tool computes or distinguishes it from near-identical siblings such as astroway_psyr_cycles_of_becoming or astroway_psychological_modern_arroyo_cycle_of_becoming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The only added text is a group tag and a credit cost, neither of which tells an agent when this tool is the right choice over the many sibling cycle-of-becoming variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
8-phase lunation classification.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| phase | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered and the bar is lower. The description adds one piece of real operational context beyond the annotations: the 10-credit Tier 1 cost, which affects an agent's decision to call it. It says nothing about the computation basis, required auth, or what a lunation phase result contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, front-loaded, and free of filler, which is good, but it is under-specified rather than concise in the productive sense. The bracketed tags consume the entire body and deliver only taxonomy and pricing, leaving no room for scope or constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 15 parameters, 4 required, and only 33% schema coverage, the description is far too thin; the one mitigating factor is that an output schema exists, so return values need not be explained. It is still missing the input premise (that a date/time/location is needed), any exclusion guidance, and any note on how the 8-phase result is produced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description bears responsibility for clarifying the remaining parameters, and it contributes nothing about any of the 15. The four required parameters (date, time, latitude, longitude) have no schema descriptions at all, and the description does not indicate that they must describe the birth/lunation moment. No syntax, units, or defaults are explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially the title restated with a qualifier: "8-phase lunation classification" against the name/title "Lunation Phase." It never states what the classification is computed from (a natal chart? a birth moment? transits?) even though the required parameters (date, time, latitude, longitude) imply chart calculation. It also gives no differentiation from the near-identical sibling astroway_psyr_lunation_phase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the many lunation/cycle siblings (rudhyar_cycles_of_becoming, psyr_lunation_phase, etc.). The [Group] and [Cost] tags are taxonomy and billing metadata, not usage guidance. An agent has nothing to route on other than the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Single-keynote signature for the chart.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| keynote | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context in the form of group and cost (10 credits, Tier 1), but does not describe output behavior, auth needs, or other operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the only substantive phrase before the metadata tags. It is concise and structured, though the brevity comes at the cost of clarity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters, 33% schema description coverage, many sibling tools, and no explanation of the Rudhyar personality keynote concept, the description is too thin. The output schema removes the need to document return values, but the description still lacks the context needed to invoke this complex tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 15 parameters and only 33% description coverage, leaving many parameters undocumented even in the schema. The description provides no parameter guidance at all, so it fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool name/title: 'Single-keynote signature for the chart' adds little beyond 'Rudhyar: Personality Keynote.' It does not explain what a keynote is or distinguish this tool from the similarly named sibling astroway_psyr_personality_keynote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, when not to use it, or which sibling tools are alternatives. The group and cost tags do not tell an agent when this specific Rudhyar personality keynote should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Symbolic-degree analysis.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| source | No | |
| ackNote | No | |
| doctrine | No | |
| perPlanet | No | |
| disclaimer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description's only added behavioral fact is the cost (10 credits, Tier 1) and group membership, which is genuinely useful for an agent deciding whether to spend credits, but it discloses nothing about coverage, computation basis, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short, but the brevity is under-specification rather than conciseness: a bare noun phrase plus two bracketed metadata tags. Nothing is front-loaded because there is nothing substantive to front-load.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter, 4-required-parameter astrology computation with defaulted timezone/precision/ayanamsa fields, the description explains nothing beyond cost and group. The existence of an output schema relieves it of explaining return values, but it still fails to say what the analysis produces or how it relates to its many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% across 15 parameters, and the description supplies zero parameter meaning to compensate. Critical fields such as cosmogram, houseSystem (bare enum letters), city, and name are undocumented in both places, so an agent must guess at their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Symbolic-degree analysis" is essentially a restatement of the tool name (Rudhyar: Symbolic Degrees) and gives no verb, no output, and no distinction from the near-identical sibling astroway_psyr_symbolic_degrees or from rudhyar_lunation_phase / rudhyar_personality_keynote. An agent cannot tell what this computes without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use, when-not-to-use, or alternative-selection guidance at all. With 40+ siblings in the Modern Psychological / Rudhyar families, the absence of any routing signal is a real gap, though nothing stated is actively misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reframe major transits as rebirth.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| source | No | |
| doctrine | No | |
| disclaimer | No | |
| rebirthThemes | No | |
| natalRebirthSignatures | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful operational metadata — the credit cost (10, Tier 1) and group — which the annotations do not convey, but says nothing about how transits are selected or what the reframing means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments, purpose first, no filler words. But the bracketed group/cost tags read as appended metadata rather than prose, and the extreme brevity is under-specification rather than efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shape needn't be restated, but for a 15-parameter astrological computation with 33% schema coverage and no usage guidance, the description leaves an agent without enough context to invoke it correctly or choose it over its many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% across 15 parameters. The description mentions no parameter at all, so it fails to compensate: notably the four required birth-data fields (date, time, latitude, longitude) and the many optionally-defaulted chart settings are left unexplained beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation on a specific object ('Reframe major transits') and echoes the title's Rudhyar/rebirth framing. However, it never says what the reframing actually produces or how it differs from the near-identical sibling astroway_psyr_transits_as_rebirth, or from astroway_psychological_modern_rudhyar_cycles_of_becoming. Vague enough that an agent cannot confidently pick it over its twins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, prerequisites, or alternative is stated. With 40+ siblings including an almost identically named transits-as-rebirth tool, the absence of routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Archetypal patterns in the chart per Liz Greene.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
(Cursor-friendly alias for astroway_psychological_modern_greene_archetypal_figures.)
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| source | No | |
| figures | No | |
| doctrine | No | |
| disclaimer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety behavior is covered. The description adds a cost signal (10 credits, Tier 1) and group membership, which is genuinely useful for an agent budgeting calls, but it discloses nothing about computation, latency, or how the psychological synthesis is derived.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short lines, front-loaded with the one-line purpose followed by group, cost, and alias metadata. Nothing is padded, though the metadata block takes up a large share of an otherwise minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters, 4 required geotemporal inputs, and no output explanation needed (an output schema exists), the definition is still thin: it never says what must be supplied, how to choose among the enum-heavy options, or what distinguishes this report from its Greene siblings. An agent could invoke it, but only by guessing at configuration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% across 15 parameters, so the description is expected to compensate and it does not mention a single input. It offers no guidance on zodiacType, ayanamsa, or houseSystem selection, which matters for a psychological report where the sidereal/tropical choice changes the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says it returns 'archetypal patterns in the chart per Liz Greene,' which is a specific resource with an attribution, but it largely restates the title 'Greene: Archetypal Figures' without saying what an archetypal figure actually is or which chart factors produce them. The alias note does clarify its relationship to the full canonical name, so it isn't fully tautological, but the purpose remains vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance and no comparison against the many Greene/Rudhyar/Arroyo siblings (individuation_path, lunar_myth, saturn_shadow, etc.). The only routing help is the parenthetical alias note pointing to the canonical tool name, which is a naming fact rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Individuation arc per natal chart.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
(Cursor-friendly alias for astroway_psychological_modern_greene_individuation_path.)
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| source | No | |
| keyAges | No | |
| doctrine | No | |
| disclaimer | No | |
| individuationMarkers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is fully covered without the description. The description does add genuinely useful behavioral context that annotations cannot: the 10-credit Tier 1 cost and the Modern Psychological grouping. It says nothing about compute time, failure modes, or what happens with incomplete birth data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short lines, front-loaded with the purpose, then group, cost, and alias. No filler sentences and the credit cost is easy to scan. The parenthetical alias line is long but does real work for cursor-based name matching.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no prose, and annotations cover the safety profile. Still, for a 15-parameter natal-chart calculation the description leaves the agent unable to judge when this arc is the right analytical lens versus a sibling Greene tool, and it adds no input guidance where schema coverage is thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% across 15 parameters, and the description contributes no parameter meaning at all. Several parameters (city, date, name, time, latitude, longitude, cosmogram, zodiacType, houseSystem, ayanamsaId) are undocumented in both places, so the description fails to compensate for the coverage gap on a tool whose correctness depends on precise birth-time and location input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Individuation arc per natal chart' names a distinct resource and its input source, so the agent knows it is a Greene-school psychological calculation rather than a raw ephemeris. However, there is no verb, no explanation of what the 'individuation arc' actually contains, and nothing that distinguishes it from the many sibling Greene tools (archetypal_figures, lunar_myth, parental_imagos, saturn_shadow) beyond the label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, no prerequisites, and no routing hints among the large set of psychological-modern siblings. The only operational note is that this is an alias for astroway_psychological_modern_greene_individuation_path, which helps with name resolution but not with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lunar archetypes by sign and house.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
(Cursor-friendly alias for astroway_psychological_modern_greene_lunar_myth.)
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| moon | No | |
| theme | No | |
| shadow | No | |
| source | No | |
| doctrine | No | |
| disclaimer | No | |
| mythicFigure | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description usefully adds the cost (10 credits, Tier 1) and the group, which are behavioral facts absent from structured fields, but says nothing about output characteristics or interpretation depth. With annotations carrying the safety burden, this is adequate but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is tightly sized and front-loads the purpose before the bracketed metadata, with zero filler. The only concern is that the brevity shades into under-specification, but structurally each line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter chart tool with only 33% parameter coverage, the description is far too sparse. Although an output schema exists (so return values needn't be explained), the definition omits any usage context, parameter guidance, or distinction from the five closely related Greene tools, leaving the agent poorly equipped to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 15 parameters at only 33% schema description coverage, and the description explains none of them. Required inputs (date, time, latitude, longitude) and key options (zodiacType, houseSystem, ayanamsaId) are left entirely to the schema, which is itself silent on several of them. The description does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource and dimensions: 'Lunar archetypes by sign and house.' However it is a bare noun phrase with no verb and no differentiation from the many Greene siblings (archetypal_figures, individuation_path, parental_imagos, saturn_shadow) that share the same group. An agent can guess the topic but not what the tool computes or returns relative to those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description supplies only a group tag, a credit cost, and an alias note, none of which tell the agent which condition should select this tool over the other Greene/psychological tools. Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parental imagos analysis.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
(Cursor-friendly alias for astroway_psychological_modern_greene_parental_imagos.)
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| source | No | |
| doctrine | No | |
| disclaimer | No | |
| shadowMarkers | No | |
| exteriorParent | No | |
| interiorParent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds one genuinely useful behavioral fact — the 10-credit Tier 1 cost — but says nothing about computation time, output shape, or prerequisites. Adding the cost signal justifies a 3 rather than lower.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short lines, front-loaded with the purpose and followed by group, cost, and alias routing metadata. Every line is compact, though the alias note is routing housekeeping rather than tool semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 described, but for a 15-parameter analysis tool the description leaves the agent without any understanding of what the analysis computes, when to select it among ~40 siblings, or meaning for the majority-undocumented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with 15 parameters and no parameter discussion anywhere in the description. It does not compensate for the undocumented date/time/latitude/longitude inputs, the 25-value houseSystem enum, or the zodiacType choice — all of which the agent must infer from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Parental imagos analysis' names the resource but never says what the tool actually produces or what a 'parental imagos' computation is. It is essentially a restatement of the title, with no verb and no differentiation from the many sibling Greene/Arroyo/Rudhyar analyses beyond the [Group: Modern Psychological] tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is given. The description supplies cost and group metadata but never tells an agent under what circumstances this analysis should be chosen over siblings like greene_archetypal_figures, greene_lunar_myth, or the psyg alias duplicates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Saturn-as-shadow integration work.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
(Cursor-friendly alias for astroway_psychological_modern_greene_saturn_shadow.)
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| saturn | No | |
| source | No | |
| doctrine | No | |
| disclaimer | No | |
| shadowTheme | No | |
| integrationPrompt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the full safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds two genuinely useful facts beyond structured data: the 10-credit Tier 1 cost and the alias equivalence. It says nothing about what the analysis returns, but an output schema exists to cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short lines, front-loaded with the subject and followed by group, cost, and alias metadata; nothing is padded. It is efficient, though the brevity reflects under-specification rather than tight writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter, 4-required astrological computation tool with 33% schema coverage and a rich sibling set, this description is far too thin. An agent gets the cost and the alias but no sense of inputs, expected analysis content, or how to choose it over the many adjacent psychological tools; only the output schema saves it from a 1.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contributes zero parameter information despite schema description coverage of only 33% across 15 parameters. Required inputs (date, time, latitude, longitude) and undocumented fields (city, name, cosmogram, zodiacType, houseSystem, ayanamsaId) have no explanation in either the schema or the description, so the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Saturn-as-shadow integration work" essentially restates the title "Greene: Saturn Shadow" without saying what the tool produces or does (a report? a chart? an interpretation?). The alias note tells the agent this duplicates `astroway_psychological_modern_greene_saturn_shadow`, which is identity information rather than purpose, and no verb+resource pairing is established.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance relative to the many Greene siblings (archetypal_figures, individuation_path, lunar_myth, parental_imagos) or the psyg/psya/psyr variants. The only routing hint is the alias parenthetical, which implies the two names are interchangeable but does not say when to prefer one or when this report is the right choice at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Outer-planet cycles as becoming.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
(Cursor-friendly alias for astroway_psychological_modern_rudhyar_cycles_of_becoming.)
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| cycles | No | |
| source | No | |
| doctrine | No | |
| currentAge | No | |
| disclaimer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds a genuinely useful behavioral fact the annotations do not carry: this call costs 10 credits (Tier 1). It says nothing about response shape or computation depth, but an output schema exists to cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short blocks with the core phrase front-loaded and no wasted prose; the alias and cost are stated compactly. It is concise but the brevity is achieved partly by omitting necessary content, which is a content problem rather than a structure one.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter chart tool with 33% schema coverage, the description is far too thin: purpose is left vague, no parameter guidance is given, and no usage context is offered. The output schema excuses it from explaining return values, but everything else an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 15 parameters and only 33% schema description coverage, the description carries a heavy compensation burden and provides none — no mention of date/time, coordinates, zodiacType, ayanamsa, houseSystem, or the compact-mode fields/precision options. An agent gets zero parameter meaning from the description beyond what the partially documented schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Outer-planet cycles as becoming" is a poetic restatement of the title ("Rudhyar: Cycles of Becoming") rather than a verb+resource statement. The only concrete information is that this is a cursor-friendly alias for `astroway_psychological_modern_rudhyar_cycles_of_becoming`, which helps name routing but does not tell an agent what the tool actually computes or returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no conditions, and no comparison against siblings such as astroway_psyr_lunation_phase or astroway_psyr_transits_as_rebirth. The group tag ("Modern Psychological") and cost tier are metadata, not usage direction; the alias note only says which duplicate name to prefer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
8-phase lunation classification.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
(Cursor-friendly alias for astroway_psychological_modern_rudhyar_lunation_phase.)
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| phase | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and a closed world, so the safety profile is fully covered. The description's only added behavioral fact is the 10-credit Tier 1 cost, which is genuinely useful for budgeting but minimal. It does not say whether the computation depends on the natal chart or the transit moment, which matters for a lunation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very terse and front-loaded: purpose first, then group, cost, and alias, each on its own bracket line. Every element carries information and nothing is padded, though the extreme brevity is as much under-specification as concision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter astrological calculation with an output schema, the description omits the context an agent needs to call it well: what inputs drive the classification, whether it needs a chart or just a moment, and how it relates to its canonical alias. The output schema spares it from explaining return values, but that is the only gap it is excused from.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% across 15 parameters, and the description adds nothing about any of them. The four required parameters (date, time, latitude, longitude) and the sidereal/tropical and house-system choices are left entirely to the schema, with the ayanamsa and timezone semantics undocumented in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the resource ('8-phase lunation classification') with a concrete taxonomy hint, but the verb is nominalized and there is no differentiation from siblings such as astroway_psyr_cycles_of_becoming or astroway_psyr_personality_keynote. The alias note tells the agent this duplicates astroway_psychological_modern_rudhyar_lunation_phase, which is useful routing information but not a statement of what the tool computes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, no mention of alternatives among the many Rudhyar/Greene/Arroyo psychological siblings. The agent is told the group and the credit cost but not the condition under which this tool (versus its canonical twin or the other Rudhyar tools) should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Single-keynote signature for the chart.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
(Cursor-friendly alias for astroway_psychological_modern_rudhyar_personality_keynote.)
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| keynote | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds a genuinely useful fact not in structured data: the 10-credit Tier 1 cost. It says nothing else about behavior, but with annotations carrying the main burden a 3 is fair.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and front-loaded: the purpose line comes first, then group/cost metadata, then the alias note. Every line is compact, though the alias sentence is only marginally valuable to a selection decision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter tool with only 33% schema description coverage, a vague one-line purpose leaves too much unexplained. Output schema existence relieves the need to describe return values, but the input side and the tool's distinct role among many near-identical siblings are not covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% across 15 parameters, and the description contributes zero parameter meaning — no mention of required date/time/lat/lon, the enum choices, compact-mode fields, or timezone handling. With a low coverage rate, the description should compensate and does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says it returns a 'single-keynote signature for the chart', which partially restates the title 'Rudhyar: Personality Keynote' without explaining what a keynote signature actually is or what it contains. It does at least identify the resource as a chart signature and flags the group, but it distinguishes nothing from siblings such as symbolic_degrees or lunation_phase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no alternatives named. The only contextual information is the credit cost and the group label, which do not tell an agent when this tool is preferable to the ~40 sibling psychological tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Symbolic-degree analysis.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
(Cursor-friendly alias for astroway_psychological_modern_rudhyar_symbolic_degrees.)
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| source | No | |
| ackNote | No | |
| doctrine | No | |
| perPlanet | No | |
| disclaimer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context: a 10-credit Tier 1 cost and the group membership, which matters for budget-aware agents. It says nothing, however, about what the analysis produces or any computational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and front-loaded, so there is no padding to trim, but the brevity comes from omission rather than efficiency: three of the four lines are metadata tags (group, cost, alias) instead of substantive content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, but for a 15-parameter geolocation-and-time chart tool the description gives no indication of required inputs, what the symbolic-degree computation yields, or how it relates to its near-identical long-name sibling. The coverage gap at 33% is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 15 parameters and only 33% schema description coverage, the description is expected to compensate and does not mention a single parameter. The alias sentence provides no parameter guidance, so several parameters (city, name, cosmogram, zodiacType, houseSystem, precision, fields) remain undocumented or thinly documented in either place.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Symbolic-degree analysis" essentially restates the tool name and title without saying what is actually computed (Sabian symbols? degree meanings? which planets?). The one piece of real information is the alias disclosure, which tells an agent this duplicates `astroway_psychological_modern_rudhyar_symbolic_degrees`, but that is a routing note rather than a purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, or prerequisite guidance is given. The alias note implies it is interchangeable with the long-named sibling, but it never says which one an agent should prefer, nor when symbolic-degree analysis is appropriate versus the other Rudhyar tools such as lunation_phase or personality_keynote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reframe major transits as rebirth.
[Group: Modern Psychological] [Cost: 10 credits (Tier 1)]
(Cursor-friendly alias for astroway_psychological_modern_rudhyar_transits_as_rebirth.)
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| date | Yes | ||
| name | No | ||
| time | Yes | ||
| fields | No | Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response. | |
| ayanamsa | No | Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either. | |
| latitude | Yes | ||
| timezone | No | IANA 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. | |
| cosmogram | No | ||
| longitude | Yes | ||
| precision | No | Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn. | |
| ayanamsaId | No | ||
| zodiacType | No | ||
| houseSystem | No | P | |
| timezoneOffset | No | Hours 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. |
| Name | Required | Description |
|---|---|---|
| source | No | |
| doctrine | No | |
| disclaimer | No | |
| rebirthThemes | No | |
| natalRebirthSignatures | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds genuinely useful context beyond that: the credit cost (10 credits, Tier 1) and the alias relationship. It does not disclose anything about output format, required inputs, or computation, so it is only modestly additive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short and front-loads the purpose before the metadata brackets, with no filler sentences. However, for a 15-parameter tool with real complexity, this level of brevity is under-specification rather than effective conciseness. Every sentence earns its place, but too little is said.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 annotations carry the safety profile. But a complex chart-calculation tool with 15 parameters, 4 required, and only 33% schema coverage leaves the agent without the required-input or parameter-selection guidance it needs to call the tool correctly. The definition is materially incomplete for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% across 15 parameters, well below the 50% threshold, so the description is expected to compensate but adds nothing. It never mentions the four required inputs (date, time, latitude, longitude) or any of the optional astrological controls (ayanamsa, houseSystem, zodiacType, timezone). The schema does carry helpful text on the few documented fields, but the description contributes zero parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific concept ('reframe major transits as rebirth') within Rudhyar psychological astrology, so the domain is identifiable. However, it never states what the tool actually produces or does computationally, and 'reframe' is metaphorical rather than a concrete verb+resource. It does not differentiate itself from the near-identical canonical sibling `astroway_psychological_modern_rudhyar_transits_as_rebirth` beyond the alias note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling psychological tools (cycles_of_becoming, lunation_phase, symbolic_degrees, etc.). The only routing hint is that it is a 'Cursor-friendly alias' for the canonical name, which tells the agent nothing about the circumstances that should select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
astroway_account_statusastroway_agent_toolsastroway_cost_estimateastroway_mcp_agent_debateastroway_mcp_agent_pool_statusastroway_mcp_ai_chatastroway_mcp_ai_comparison_coachastroway_mcp_ai_explain_aspectastroway_mcp_ai_explain_transitastroway_mcp_multi_agent_coordinateastroway_mcp_multi_chart_contextastroway_mcp_rag_searchastroway_mcp_streamingastroway_mcp_tool_call_streamastroway_mcp_tools_listastroway_psya_cycle_of_becomingastroway_psya_element_balanceastroway_psya_element_integrationastroway_psya_relational_element_mapastroway_psya_water_houses_traumaastroway_psychological_modern_arroyo_cycle_of_becomingastroway_psychological_modern_arroyo_element_balanceastroway_psychological_modern_arroyo_element_integrationastroway_psychological_modern_arroyo_relational_element_mapastroway_psychological_modern_arroyo_water_houses_traumaastroway_psychological_modern_greene_archetypal_figuresastroway_psychological_modern_greene_individuation_pathastroway_psychological_modern_greene_lunar_mythastroway_psychological_modern_greene_parental_imagosastroway_psychological_modern_greene_saturn_shadowastroway_psychological_modern_rudhyar_cycles_of_becomingastroway_psychological_modern_rudhyar_lunation_phaseastroway_psychological_modern_rudhyar_personality_keynoteastroway_psychological_modern_rudhyar_symbolic_degreesastroway_psychological_modern_rudhyar_transits_as_rebirthastroway_psyg_archetypal_figuresastroway_psyg_individuation_pathastroway_psyg_lunar_mythastroway_psyg_parental_imagosastroway_psyg_saturn_shadowastroway_psyr_cycles_of_becomingastroway_psyr_lunation_phaseastroway_psyr_personality_keynoteastroway_psyr_symbolic_degreesastroway_psyr_transits_as_rebirthSynastry, composite, compatibility scores, family dynamics and pet charts.
Transits, progressions, directions, returns, cosmobiology and evolutionary technique.
Lots, sect, triplicity rulers, zodiacal releasing, annual profections and horary.
Real astrology for AI agents: cosmic weather, synastry, timing, astrocartography, and divination.
Add one secure layer between your agents and this server.
