Skip to main content
Glama
Sign In
StarGazer1995

mcp-stargazing

by StarGazer1995
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_weather_by_position

Retrieve current conditions plus hourly and daily forecasts using latitude and longitude coordinates to assess stargazing weather.

Instructions

通过经纬度获取综合天气（当前 + 小时预报 + 日预报）。

Use when: you have precise coordinates and need current and forecast weather facts. Do not use when: you only have a place name or need ranked observing sites or night targets. Requires: latitude and longitude; provider selection can remain at the default policy. Follow-up: get_weather_by_name for place-name input; plan_stargazing_session to compare observing places and nights using weather and other evidence.

Weather data is aggregated from multiple providers with graceful fallback. Open-Meteo needs no API key; network/provider failures can still occur. Atmospheric fields: summary.current.atmosphere and summary.hourly[*].atmosphere contain optional model estimates with their own valid time and per-field provenance. Inspect summary.atmosphere_sources for source failures and resolution. Missing/null means unknown. CAMS global is approximately 45 km and natively 3-hourly; hourly output may be interpolated. AOD is column extinction, not surface visibility. Boundary-layer height is above local model ground, not a pollution ceiling. No AQI or pollution attribution is inferred. Interpretation: summary.current is current weather, summary.daily is calendar-day aggregation, and summary.hourly contains timestamped forecasts. For a future observing night select the actual hourly timestamps across local midnight and inspect providers and source for failures/provenance. Missing/null or out-of-horizon hours are unknown, not clear weather. Forecasts are predictions, not observations of future conditions; do not assume all providers or fields cover the same dates.

Args: lat: 纬度 lon: 经度 provider: provider 模式，可选 all/qweather/open-meteo/wttr。

Returns: Dict，包含 keys: "data", "_meta"（成功时）或 "error", "_meta"（失败时）。

Input Schema

NameRequiredDescriptionDefault
latYes
lonYes
providerNoall

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.2
    • addedInput schema / properties / provider
      Added value: +{
+  "default": "all",
+  "type": "string"
+}
  2. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden and does so well: multi-provider aggregation with graceful fallback, Open-Meteo requires no API key, failures can still occur, CAMS grid resolution and 3-hourly interpolation caveats, and explicit warnings that forecasts are predictions and that missing/null or out-of-horizon hours mean unknown (not clear). Remaining gaps are minor — no mention of timeouts, rate limits, or caching behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Strong front-loading with labeled sections (Use when / Do not use when / Requires / Follow-up / Returns), but the middle block is bloated and repeats itself — 'Missing/null means unknown' appears twice in slightly different wording, and the atmospheric-field exposition is longer than needed for tool selection. Useful content, not tightly edited, and it mixes Chinese and English.

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?

With no annotations, no output schema, and 0% schema coverage, the description steps in to document arguments, the return shape ('data'/'_meta' on success, 'error'/'_meta' on failure), provenance fields, and interpretation rules for current vs. daily vs. hourly. Nothing essential to calling or interpreting the result is missing.

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 0%, so the description must compensate — it does partially by naming all three args and enumerating provider modes (all/qweather/open-meteo/wttr), which the schema itself lacks (0 enums declared). However it never explains what each provider mode implies (coverage, latency, key requirements) or that 'all' is the default, leaving the agent to infer provider trade-offs.

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?

The first line states a specific verb+resource+scope: retrieve comprehensive weather (current + hourly + daily) by latitude/longitude. It immediately distinguishes itself from the sibling get_weather_by_name via the coordinate-based path, so an agent can route between the two without inspecting schemas.

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

Usage Guidelines5/5

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

Explicit 'Use when' (you have precise coordinates), 'Do not use when' (only a place name, need ranked observing sites, or night targets), and 'Follow-up' routing to get_weather_by_name and plan_stargazing_session. This is textbook when/when-not/alternatives coverage.

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