Skip to main content
Glama
Sign In
meteor-mcp

meteor-mcp

by qso-graph
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Meteor Source Info

meteor_source_info
Read-onlyIdempotent

Provides source provenance and citation guidance for meteor shower data and live feeds, including edition, checksum, and licence.

Instructions

Where every number in this server comes from, and how to cite it.

The shower list is the IAU Meteor Data Center's, carried in the package with its checksum so the exact edition served is identifiable. The live sources are named with their licences. Nothing here is this project's own measurement, and the citations are the owners' own.

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

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.8/5.0
Behavior4/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 bar is lower; the description still adds real context by naming the IAU Meteor Data Center as the shower-list owner, noting a bundled checksum identifying the exact edition served, and stating that live sources are named with their licences. It does not cover response shape, but an output schema exists, so that omission is minor.

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 lead sentence front-loads the purpose, and the following sentences each add distinct provenance facts (IAU MDC origin, checksum, licences, non-original measurement). The phrasing is slightly literary ("Nothing here is this project's own measurement"), but it is short and no sentence is pure filler.

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 zero-parameter, read-only metadata tool with an output schema, the description supplies enough about sources, licensing and citation to call it correctly and interpret results. A brief note on how citations are formatted or whether they are directly reusable would round it out.

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 no parameters, which is the baseline-4 case; the description correctly implies a parameterless informational call and introduces no confusing input expectations. Nothing further is needed or supplied.

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 line, "Where every number in this server comes from, and how to cite it," states the resource (data provenance and citations) concretely enough that an agent can predict what it returns. It does not use a strict verb+resource form and never contrasts itself with the potentially overlapping sibling get_version_info, 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.

Usage Guidelines3/5

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

The phrase "how to cite it" implies the use case of attributing or referencing the server's data, but there is no explicit statement of when to call this versus siblings such as get_version_info or meteor_shower_info. Usage is implied rather than directed.

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