Skip to main content
Glama
Sign In
mcp-stargazing

mcp-stargazing

by StarGazer1995
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_weather_by_name

Fetch current, hourly, and daily weather for a named location, resolving place names for stargazing planning.

Instructions

通过地点名称获取综合天气（当前 + 小时预报 + 日预报）。

Use when: you have a place name and need weather facts for that resolved location. Do not use when: you already have exact coordinates or need a complete observing decision. Requires: an unambiguous place name; use full administrative names for Chinese locations. Provider selection can remain at the server's default aggregation policy. Follow-up: get_weather_by_position for precise coordinates; plan_stargazing_session to combine weather with darkness, targets, and alternative observing sites.

Geocoding uses offline China gazetteer (CJK) → Photon → Nominatim cascade. 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.

中文地名提示：建议使用完整行政区划名称，如 "浙江安吉"、"杭州西湖区"。 内置离线行政区划数据会正确解析到对应的行政区（如安吉县），而非 POI 商铺。 需要精确定位时优先使用 get_weather_by_position(lat, lon)。

Args: place_name: 地点名称。中文请使用完整行政区划（如 "浙江省安吉县"），避免仅用2-3字短名。 provider: provider 模式，可选 all/qweather/open-meteo/wttr。

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

Input Schema

NameRequiredDescriptionDefault
providerNoall
place_nameYes

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.5/5.0
Behavior4/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 substantial work: it discloses the geocoding cascade (offline CJK gazetteer → Photon → Nominatim), multi-provider aggregation with graceful fallback, that Open-Meteo needs no API key, and that network/provider failures occur. It also sets interpretation rules (missing/null means unknown, not clear; forecasts are predictions) and field caveats (CAMS ~45 km and 3-hourly interpolated, AOD is column extinction not visibility, boundary-layer height is not a pollution ceiling). It stops short of stating rate limits, caching, or timeout behavior, which keeps it from a 5.

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?

The front-loading is good — Use when / Do not use when / Requires / Follow-up appear before the field-interpretation prose. But the text is bloated and redundant: the place_name full-administrative-name advice appears in the Args section and again in the Chinese tip, and get_weather_by_position is recommended twice in different places. Several atmospheric-caveat sentences read as documentation for downstream consumers rather than for a caller choosing and invoking this tool.

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?

There is no output schema, and the description compensates by naming the return shape ("data"/"_meta" on success, "error"/"_meta" on failure) and explaining how to read summary.current, summary.hourly, summary.daily, and summary.atmosphere_sources. For a geocoding-plus-aggregation tool whose results are easy to misinterpret, this covers what a caller needs to invoke it and read the result correctly.

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%, so the description must compensate, and it does: place_name guidance specifies full administrative names and explicitly warns against 2-3 character short names, with concrete examples ("浙江安吉", "杭州西湖区"). It also enumerates provider values (all/qweather/open-meteo/wttr) that are absent from the schema enum, though it never explains what each mode returns or the tradeoffs between them.

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?

Opens with a specific verb+resource and scope: "获取综合天气（当前 + 小时预报 + 日预报）" by place name. It immediately differentiates from the sibling get_weather_by_position ("already have exact coordinates"), so an agent can route between the two without opening either schema.

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?

Has explicit "Use when" and "Do not use when" clauses plus a "Requires" precondition (unambiguous place name, full administrative names for Chinese locations). It names two concrete follow-up alternatives (get_weather_by_position for coordinates, plan_stargazing_session for observing decisions), making the when-not guidance actionable.

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