Skip to main content
Glama

upcoming_launches

Fetches upcoming rocket launches with a configurable limit, enabling you to track scheduled space missions.

Instructions

今後予定されているロケット打ち上げの一覧を返す。

Args: limit: 返す件数(既定 5、最大 15)。

Input Schema

NameRequiredDescriptionDefault
limitNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.41.4
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • removedInput schema / title
      Removed value: -"upcoming_launchesArguments"
  2. Changed1 schema field changedv0.25.2
    • changedOutput schema / (root)
      Previous value: -{
      -  "properties": {
      -    "result": {
      -      "title": "Result",
      -      "type": "string"
      -    }
      -  },
      -  "required": [
      -    "result"
      -  ],
      -  "title": "upcoming_launchesOutput",
      -  "type": "object"
      -}New value: +null
  3. First observedv0.1.0

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description carries the full burden and does little: it does not say where the launch data comes from, how far into the future the list extends, whether non-rocket launches (e.g. suborbital) are included, or how fresh the data is. Only the parameter bounds are disclosed.

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, purpose first, parameter detail second — no filler. The Japanese docstring-style 'Args:' block is slightly formal but well organized.

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?

For a one-parameter, no-output-schema tool this is close to adequate, but it never describes what an entry contains (launch vehicle, provider, date/time, site) or the time window covered, which an agent needs to decide whether the result answers the user's question.

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?

Schema coverage is 0% and the schema only records a default of 5, but the description adds the meaningful constraint that 15 is the maximum, which the schema does not express. It stops short of saying what happens when a larger value is requested, but the added meaning is real.

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 and resource: returns a list of upcoming rocket launches. An agent can tell it is a launch-listing tool, but the description never clarifies scope relative to siblings like china_launches or russia_launches, so whether this is the global/aggregate feed or something else must be inferred.

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?

There is no when-to-use guidance, no exclusions, and no mention of the country-specific launch tools as alternatives. The agent is left to guess whether to call this or china_launches/russia_launches.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.