Skip to main content
Glama
astroway

astroway-mcp

Official
by astroway

Algol Minimum

astroway_calendar_algol_minimum
Read-onlyIdempotent

Find the minimum-brightness moment of Algol (Beta Persei) within a date range to plan observations or timing around this eclipsing variable star.

Instructions

Find the nearest minimum brightness moment of Algol (Beta Persei), the eclipsing variable star, within a date range.

[Group: Calendar & Cycles] [Endpoint: POST /v1/algol-minimum] [Required: startDate, endDate] [Cost: 10 credits (Tier 1)]

Input Schema

NameRequiredDescriptionDefault
endDateYes
longitudeNo
startDateYes

Output Schema

NameRequiredDescriptionDefault
countNo
minimaNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare a safe, idempotent read operation, and the description adds the 10-credit cost tier and endpoint, which are useful operational context. It does not disclose what the response contains or how precisely the minimum is computed, but with annotations covering safety and an output schema present, this is adequate.

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

Conciseness4/5

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

The core sentence is front-loaded and waste-free, and the bracketed metadata lines (group, endpoint, required params, cost) are compact and scannable. Slightly repetitive with the schema for required parameters, but not verbose.

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

Completeness3/5

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

Safety and return shape are covered by annotations and the output schema, and cost is stated, but the undocumented longitude parameter is a substantive gap for a tool whose answer depends on observer position. An agent could call it correctly for the minimal case but would not know what longitude is for.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry the burden, yet it only gestures at "within a date range" and never addresses the third parameter, longitude, whose effect on an Algol minimum (observer-dependent timing/visibility) is left completely unexplained. The date format is also only in the schema.

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

Purpose4/5

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

States a specific verb ("Find") and a precisely named resource ("nearest minimum brightness moment of Algol (Beta Persei)") with scope limited to a date range. It does not, however, distinguish itself from the sibling astroway_calendar_algol_minimum_nearest, whose name suggests a nearly identical function, leaving ambiguity unresolved.

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

Usage Guidelines2/5

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

The description gives no guidance on when to use this tool rather than astroway_calendar_algol_minimum_nearest or other calendar/cycle tools, and states no prerequisites or exclusions. A reader 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.

Deploy Server

Other Tools