Skip to main content
Glama
Sign In
meteor-mcp

meteor-mcp

by qso-graph
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Meteor Activity

meteor_activity
Read-onlyIdempotent

Counts meteors confirmed today by the Global Meteor Network, broken down by shower, with generation time and attribution.

Instructions

How many meteors the Global Meteor Network has actually confirmed today.

A count of observed trajectories broken down by shower — not a flux density, which is a different quantity GMN computes separately. The file is written during the day, so an early read covers a partial day; the generation time is in the answer.

This reads the network. Attribution is a condition of GMN's CC BY 4.0 licence and is carried in the result.

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_activity"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, open-world behavior, so the description clears the lower bar. It adds genuinely useful context beyond them: partial-day coverage on early reads, the generation timestamp being included in the response, and the CC BY 4.0 attribution condition carried in 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.

Conciseness4/5

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

The core answer (what is counted) is front-loaded in the first sentence, followed by caveats and licence terms in descending order of importance. The forced line breaks add little but no sentence is filler.

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

Completeness5/5

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

An output schema exists, so return shape need not be explained. The description still covers the things structured fields cannot: data freshness/partial-day semantics, the precise quantity being counted, and attribution obligations.

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

Parameters4/5

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

The tool takes zero parameters, so there is no parameter meaning to add; baseline 4 applies. The description correctly does not waste space describing inputs that do not exist.

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?

"How many meteors the Global Meteor Network has actually confirmed today" names a specific metric, source, and time window, and explicitly rules out conflating it with flux density. It does not differentiate against named siblings such as meteor_fireballs or meteor_showers, so an agent must infer the boundary from the noun alone.

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

Usage Guidelines3/5

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

Usage is implied (call this for a current-day confirmed count) and the 'not a flux density' clause prevents a specific misuse. However, no alternative tool is named for other quantities or other time ranges, and no explicit when-not-to-use condition is stated.

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