Skip to main content
Glama
Sign In
meteor-mcp

meteor-mcp

by qso-graph
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Meteor Fireballs

meteor_fireballs
Read-onlyIdempotent

Retrieve NASA CNEOS fireball reports to identify bright bolides detected from orbit; configure the number of events returned (default 10, max 100).

Instructions

Recent fireballs recorded by NASA CNEOS.

Bolides bright enough to be detected from orbit — the "did anyone else see that" events, not a meteor rate. Reads the network.

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

Input Schema

NameRequiredDescriptionDefault
limitNoHow many of the most recent to return. Default 10, at most 100.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, so safety is covered structurally. The description adds genuine context beyond that: the upstream source (NASA CNEOS) and the selection criterion (bright enough to be detected from orbit). It says nothing about update cadence or latency, which is the remaining gap.

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?

Two short sentences, front-loaded with the core fact (source + recency) before the disambiguating clause. The colloquial 'did anyone else see that' phrasing is informal but functional, since it conveys the granularity of the data rather than decoration.

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?

For a one-parameter read tool with rich annotations and an output schema, the description covers source, granularity and the key disambiguation. Only freshness/cadence of the CNEOS feed is unstated, which is a minor gap given the return shape is defined elsewhere.

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 description coverage is 100% and the single 'limit' parameter is fully documented (default 10, max 100), so the schema carries parameter meaning. The description only reinforces recency ordering ('most recent'), adding no syntax or format beyond what is already structured.

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

Purpose5/5

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

States a specific resource (fireballs recorded by NASA CNEOS) and scopes it to recent events. The clarifying clause 'not a meteor rate' preempts the most likely confusion with a rate/activity sibling, so an agent can distinguish it 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.

Usage Guidelines4/5

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

Implies the use case clearly ('did anyone else see that' events = individual bright bolides) and gives a negative boundary against rate-style queries. It stops short of naming an explicit alternative tool to call for meteor rates, so routing is left partly to inference.

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