Skip to main content
Glama
Sign In
meteor-mcp

meteor-mcp

by qso-graph
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Meteor Showers

meteor_showers
Read-onlyIdempotent

Ranks meteor showers by proximity to peak for a given UTC instant, showing which are closest or at maximum. Converts IAU solar-longitude maxima into dates.

Instructions

Which showers are near their peak, closest first.

The IAU MDC publishes each maximum as a solar longitude rather than a date, because solar longitude names the same point in the stream every year while a date drifts. The longitude is converted here to the date it falls on in the year asked about.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "meteor_showers"
  }
}

Input Schema

NameRequiredDescriptionDefault
whenNoUTC instant to rank around, ISO 8601. Omitted, now.
limitNoHow many to return. Default 12.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A3.5/5.0
Behavior3/5

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 real value by disclosing the result ordering and the solar-longitude-to-date conversion, which explains why maxima are recomputed per year rather than fixed dates. It still says nothing about the size or shape of the response beyond ordering.

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 answer is front-loaded in one sentence, followed by a short rationale paragraph that explains a genuinely non-obvious modeling detail (solar longitude vs. date). The explanation is slightly long for its payoff but every clause supports understanding the returned dates.

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

Completeness4/5

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

With an output schema present, annotations covering safety, and full parameter documentation, the description only needs to add the ordering and derivation logic, which it does. An agent has enough to call the tool correctly and interpret the ordering, though the relationship to siblings remains unspecified.

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

Parameters3/5

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

Schema coverage is 100%, with both 'when' (ISO 8601 UTC instant, defaults to now) and 'limit' (default 12) fully documented in the schema. The description only indirectly touches parameters via 'the year asked about,' which hints that 'when' determines the year used for the conversion. Baseline 3 applies since the schema does the heavy lifting.

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?

The opening sentence names a specific resource (showers) and a specific result shape: those near their peak, ordered closest first. That is more than a restatement of the name and gives an agent a concrete notion of the output, though it never contrasts itself with siblings like meteor_activity or meteor_shower_info.

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

Usage Guidelines3/5

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

The phrase 'near their peak, closest first' implies the use case (finding imminent showers around a given instant) but there is no explicit when-to-use/when-not guidance and no named alternative for, say, per-shower detail or general activity levels. Usage must be inferred from the result description.

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