spaceweather-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct aspect of space weather (current conditions, forecasts, alerts, indices, solar activity, events) with clear boundaries. No significant overlap.
Naming Consistency5/5
All tools follow a consistent 'get_' or 'list_' prefix followed by a descriptive noun phrase, making the action and resource clear.
Tool Count5/5
15 tools is well-scoped for the space weather domain, covering essential data sources without being overwhelming.
Completeness5/5
The set covers current conditions, forecasts, alerts, solar activity, geomagnetic indices, magnetometer data, and event catalogs, leaving no obvious gaps for typical space weather queries.
Average 4.2/5 across 15 of 15 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states 'newest first', 'type-specific summary', and 'DONKI link', implying read-only behavior, but does not explicitly confirm read-only, rate limits, or pagination.
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 description is somewhat lengthy but front-loaded with the main purpose. It uses backticks for event types, adding structure. Could be more concise by removing redundant phrasing.
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?
Given an output schema exists, the description adequately covers return content (type-specific summary, DONKI link). It mentions the catalog nature and source. Missing details on pagination or limits, but acceptable for a list tool.
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 coverage is 0%, so the description adds value by explaining the event_type enum with meanings and noting type-specific summaries. However, 'days' parameter (default 7) is not explained, leaving ambiguity about its meaning.
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 description clearly states it catalogs space-weather events from NASA DONKI, listed newest first, and lists event types. It differentiates itself as a structured catalog complementing real-time feeds, though it does not explicitly name sibling tools.
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 description mentions it complements real-time SWPC feeds, giving a hint about when to use it, but lacks explicit when-not-to-use guidance or direct comparisons to siblings like get_alerts or get_solar_flares.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It discloses that results are in plain-text format and ordered newest first, but it does not mention pagination, rate limits, or behavior when no alerts exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose, provides concrete examples, and contains no extraneous information. Every sentence adds value.
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 simple tool with one optional parameter and an output schema, the description covers the overall purpose and format but omits the limit parameter. It is mostly complete but has a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (limit) is not mentioned in the description. With 0% schema description coverage, the description should explain the parameter meaning, but it fails to do so. The parameter name 'limit' is somewhat self-explanatory, but the tool definition does not add value.
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 description clearly states the tool returns the most recent NOAA SWPC alerts, watches, and warnings (newest first), and gives examples like geomagnetic storm watches. This distinguishes it from sibling tools that focus on specific phenomena or forecasts.
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 description implies the tool is for general alerts but does not explicitly state when to use it vs. alternatives like get_solar_flares or get_aurora_forecast. No when-not-to-use or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the two modes (with/without coordinates) and output format (probability percent or peak). However, it does not mention limitations, model accuracy, or coordinate format (likely decimal degrees), leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences front-load the model and time range. Every sentence is purposeful, with no wasted words. Structure is ideal for quick agent comprehension.
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?
Given the presence of an output schema (not shown), the description does not need to detail return format. It covers the two parameter modes and output semantics. However, it could explicitly state coordinate format (decimal degrees) for completeness.
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 description coverage is 0%, so description must add meaning. It clearly explains that latitude and longitude are optional and affect output: if provided, returns probability at that location; if omitted, returns peak probability over the oval. This adds significant value beyond the schema.
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 description clearly states it provides a short-term (~30-90 min) auroral-oval forecast using OVATION model. It distinguishes itself from sibling tools like get_kp_forecast by specifying the time range and output (probability at location or peak).
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 description implies usage for short-term aurora prediction ('will I see aurora tonight?') but does not explicitly contrast with siblings or state when not to use it. Usage guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the source (NOAA SWPC) and the data fields, but does not mention behavioral traits such as data freshness, update frequency, or what happens if no active regions are present. It is adequate but lacks some details an autonomous agent could benefit from.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that front-load the key purpose and data details. Every sentence contributes meaning, with no redundancy or wasted words.
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?
Given that the tool has no parameters and an output schema exists, the description adequately explains the data provided: location, area, spot/magnetic class, and flare/proton probabilities. It could be slightly improved by noting the update frequency or timestamp, but overall it is complete enough for use.
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 has zero parameters, so the parameter semantics dimension baselines at 4. The description does not need to add parameter info because there are none, and the schema coverage is 100%.
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 description clearly states that the tool retrieves today's active sunspot regions with flare probabilities from NOAA SWPC, and it lists specific per-region data like location, area, class, and probabilities. It also answers the specific questions 'how many sunspot regions / which is most likely to flare?' This distinguishes it from siblings like get_solar_flares or get_aurora_forecast.
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 description explains what data the tool provides (active sunspot regions with flare probabilities) and what questions it answers, giving context for use. However, it does not explicitly state when to use this tool over alternatives (e.g., when to use get_solar_flares instead) or any prerequisites, so the guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers some behavioral aspects: data source, provisional status, and usage restrictions. However, it does not mention rate limits, authentication requirements, or behavior for large 'days' values. The disclosure adds value but is not exhaustive.
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 description is efficient: two paragraphs with no filler. The first paragraph defines the tool's purpose and the Dst scale, while the second covers licensing and attribution. It is front-loaded and each sentence serves a purpose. Slight redundancy in the citation instruction could be trimmed.
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?
Given the tool's simplicity (one optional param, output schema exists), the description explains the data's meaning, source, and usage constraints. It provides the Dst interpretation scale. It does not specify error handling or data availability, but the output schema likely covers that.
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 schema has 0% description coverage, so the description must clarify the parameter. It states 'over the last `days`' which explains that 'days' specifies the time range. This adds meaning beyond the schema's type and default, though it does not constrain input range or format.
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 description clearly states the tool returns the hourly Dst index over a specified number of days, explains the Dst scale, and distinguishes itself from siblings by noting the data source (WDC Kyoto) and its non-commercial nature. The verb 'get' and resource 'hourly Dst index' are specific and unambiguous.
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?
The description implies usage for obtaining Dst index data and provides context about licensing and citation, which helps the agent decide when to use this tool. However, it does not explicitly state when not to use it or list alternatives for related indices like Kp or solar wind, leaving some implicit inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the data source (GOES) and derivation of the S-scale, but does not mention data latency, caching, or any limitations. For a read-only tool this is acceptable but not comprehensive.
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 description is concise at three sentences, front-loading the main purpose and providing necessary detail. No redundant information.
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?
Given zero parameters and existence of an output schema, the description adequately explains what the tool returns and its relevance. It provides sufficient context for a simple data retrieval tool.
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?
No parameters exist, and schema coverage is 100%. According to guidelines, baseline is 4. The description does not need to add parameter meaning.
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 description clearly states it provides the current solar radiation environment and NOAA S-scale, including specific data like GOES integral proton flux and derived scale. The purpose is specific and distinct from sibling tools like get_aurora_forecast or get_solar_wind.
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?
The description mentions relevance to satellite operations, polar flights, and astronaut radiation exposure, indicating when to use it. However, it does not explicitly exclude or compare to alternatives, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It accurately discloses that the tool returns forecast data (today + 3 days) with scale levels and a headline summary. This is sufficient for a read-only information retrieval tool, though it could mention data source freshness if applicable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise with two sentences. The first sentence introduces the three scales, and the second details the return format and time range. Every word contributes value without redundancy.
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?
Given the tool has no parameters and an output schema exists (so return structure is documented), the description is complete enough. It specifies the time range (today + 3 days), data fields (scale level and label), and a headline. Minor gap: no mention of what each scale level represents numerically.
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?
There are zero parameters, and the schema has 100% coverage trivially. The description adds no parameter details, which is acceptable since none exist. The baseline for 0 parameters is 4.
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 description clearly identifies the tool as returning NOAA G, S, R scales, including a specific verb ('returns') and resource (the three scales). It distinguishes from siblings by specifying the unique combination of geomagnetic, solar radiation, and radio blackout indices, while sibling tools like get_kp_forecast or get_radiation_storm focus on individual indices.
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 description implies use for retrieving today's and next 3 days' scale forecasts, but lacks explicit guidance on when to use this tool versus alternatives (e.g., get_kp_forecast for Kp index). No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It reveals that the tool fetches recent flare event data with begin/peak/end times and peak class. However, it omits details on data freshness, rate limits, or whether the operation is read-only (though that is implied). The output description is partially covered by the existing output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a usage tag, front-loading the core purpose. Every sentence adds value with no redundancy or fluff.
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 simple tool with one parameter and an output schema, the description adequately covers purpose, parameter, output format, and usage context. It could mention potential limitations (e.g., maximum days, data source) but is sufficient for effective agent selection.
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 only parameter 'days' is explained in the description as 'last `days`', clearly indicating it controls the lookback window. Since the input schema has no description and only declares type and default, this addition is meaningful and compensates for the 0% schema coverage.
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 description clearly states it returns 'Recent GOES X-ray solar flares' with specific classes (C/M/X), and explicitly distinguishes itself by noting it's best for current flare activity queries. This verb+resource combination effectively sets it apart from sibling tools like get_aurora_forecast or get_kp_index.
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?
The description provides explicit usage guidance: 'Best for "biggest recent flare?" / current flare activity.' This indicates when the tool is appropriate, though it does not explicitly list exclusions or alternatives. The sibling tools are distinct enough that no further disclaimers are necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the source satellites, data fields with units and coordinate system, and a practical use case. It does not specify data freshness, latency, or authentication requirements, but given the tool's simplicity, the transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first introduces source and data type, second details return fields and units, third adds context on usage. No redundant information, and key details are front-loaded.
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?
Given the tool's scope, the description covers source, output fields, and a use case. An output schema exists (not shown), so return structure is partially documented. Missing details like data update frequency or historical availability, but overall complete for a simple query tool.
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 coverage is 0%, so description must explain parameters. It mentions 'for the chosen window' but does not explicitly list the enum values or describe the window parameter. The enum values are in the schema, but the description adds minimal semantic value beyond that. Baseline 3 is appropriate.
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 description clearly states that the tool retrieves real-time solar wind data from DSCOVR/ACE at L1, specifically magnetic field and plasma parameters. It distinguishes from sibling tools like aurora forecasts or Kp indices by focusing on raw solar wind measurements, making the purpose unambiguous.
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?
The description implies use for monitoring solar wind conditions, especially for geomagnetic storm drivers, by mentioning Bz and speed. However, it does not explicitly state when to use this tool versus alternatives or when not to use it, though the sibling list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes output format but lacks details like whether it returns all observatories, caching, or side effects. With no annotations, more behavioral context would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with purpose.
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?
Adequate for a zero-parameter tool with an output schema. Could explicitly state it lists all USGS observatories, but context is sufficient.
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?
No parameters; baseline 4 applies. Description adds value by explaining the output, which compensates for lack of parameters.
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?
Clearly states it lists USGS magnetic observatories, returns IAGA codes, names, and coordinates. Distinguishes from sibling get_observatory by describing the list purpose.
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 usage before get_observatory to choose a station near a region of interest. No explicit when-not but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states data is U.S. public domain and preliminary, but does not mention authentication, rate limits, or the fact that it is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three sentences that front-load the purpose and provide essential details without redundancy. Every sentence adds value.
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?
Given the presence of an output schema (not shown), the description does not need to explain return values. It covers the data type, available components, temporal scope, and data provenance. It also references a sibling tool (list_observatories) for station codes.
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?
Despite 0% schema description coverage, the description explains the station parameter as an IAGA code from list_observatories, hours as the time window, elements as field components with defaults, and sampling_period with usage recommendations. It adds meaning beyond the schema's parameter names.
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 description clearly states the tool returns 'Ground magnetometer time series for one USGS observatory (nT).' It specifies the exact resource (magnetometer data per observatory) and distinguishes from sibling tools that focus on other space weather data like solar wind or Kp indices.
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?
The description provides usage guidance: 'Use 60s sampling for trends, 1s for detail (heavier)' and notes that station codes come from list_observatories. It also mentions that near-real-time values are preliminary. However, it does not explicitly state when to avoid using this tool or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that each data point is tagged as observed/estimated/predicted, indicating the nature of the data. It also states the source (NOAA) and resolution. This adds value beyond a simple schema, though update frequency or limitations are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the core function, second adds detail and use case. No wasted words, front-loaded with key information.
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?
Given the tool's simplicity (no parameters, output schema present), the description covers the essential: source, resolution, data tagging, and use case. Missing details like update cadence or data freshness, but overall sufficient for an AI agent to understand and select the tool.
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?
There are zero parameters, so the baseline is 4. The description adds no parameter information because none exist, but the schema coverage is 100%.
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?
Description clearly states the tool provides NOAA's 3-day planetary Kp forecast at 3-hour resolution, which is a specific verb (fetch) and resource (Kp forecast). It distinguishes from siblings by mentioning '3-day' and '3-hour resolution', which contrasts with longer-term outlooks or current conditions.
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?
The description notes the tool is useful for aurora-watch planning and anticipating geomagnetic disturbance, providing clear context. However, it does not explicitly state when not to use it or mention alternatives (e.g., get_27day_outlook for longer horizon).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behavioral traits: observed data (not forecast), time series nature, cadence, range, and storm threshold. Does not mention output format, but output schema exists to cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences with no filler. Key information (cadence, range, usage) is front-loaded and every sentence adds value.
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?
Fully adequate for a zero-parameter tool with output schema present. Covers what data is returned, its time range, and usage context. Could optionally mention return structure, but not necessary.
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?
No parameters exist, so the description cannot add meaning beyond schema. Baseline 4 applies as the description correctly handles the absence.
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 description clearly states the tool returns observed planetary K-index time series, specifying cadence (3-hour) and recency (~last week). It distinguishes from siblings like get_conditions_now (single current value) and get_kp_forecast (forecast).
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?
Provides explicit guidance: use for trend/history, and directs to get_conditions_now for current value. Could also mention get_kp_forecast as an alternative for predictions, but the given guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses the tool's purpose and output (current snapshot, specific data fields). It does not mention any behavioral traits like data freshness or caching, which could be useful but are not critical given the tool's simplicity and lack of parameters or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first sentence defines the purpose, the second elaborates on output and usage. No redundancy or extraneous information.
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?
Given no parameters and an output schema, the description covers all needed context: what the tool does, what it returns, and when to use it. It is self-contained for an agent to select and invoke 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?
There are zero parameters, so schema description coverage is 100%. The description adds value by detailing what the snapshot contains (Kp, Bz/Bt, solar wind, NOAA scales, etc.), which goes beyond the empty schema.
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 description clearly states 'Single-call snapshot of current space weather' and lists the specific data returned (Kp, Bz/Bt, solar wind, NOAA scales, geomagnetic storm status, summary). It distinguishes itself from sibling tools by positioning as the best first call for 'what's space weather doing right now' questions.
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?
The description explicitly tells when to use: 'Best first call for "what's space weather doing right now / will I see aurora" questions.' It implies that for detailed or specific parameters, other sibling tools like get_kp_index or get_solar_wind would be more appropriate, though it does not name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the data content (daily F10.7, Ap, Kp), the time horizon (27-day outlook), and the coarseness relative to the 3-day forecast. Lacks specifics on data source reliability or update frequency, but sufficient for a read-only outlook tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the key data types and utility. Every sentence adds value; no redundancy or fluff.
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?
Given zero parameters and an output schema, the description fully explains what the tool provides, its time horizon, and how it fits with sibling tools. No gaps remain.
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?
Input schema has zero parameters and 100% schema coverage, so baseline is 4. Description does not add parameter-specific info but clarifies the output content, which is helpful but not required for parameter semantics.
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 description clearly states it provides a 27-day outlook of F10.7 radio flux, planetary Ap, and largest Kp. It distinguishes from the 3-day Kp forecast by noting coarser granularity and longer-range planning utility, differentiating it from siblings like get_kp_forecast.
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?
Explicitly states when to use: for longer-range planning due to its 27-day look-ahead, and contrasts with the coarser 3-day Kp forecast, suggesting the alternative tool for shorter-term needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![spaceweather-mcp MCP server](https://glama.ai/mcp/servers/hoon1983/spaceweather-mcp/badges/card.svg)](https://glama.ai/mcp/servers/hoon1983/spaceweather-mcp)

Score Badge

Copy to your README.md:

[![spaceweather-mcp MCP server](https://glama.ai/mcp/servers/hoon1983/spaceweather-mcp/badges/score.svg)](https://glama.ai/mcp/servers/hoon1983/spaceweather-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hoon1983/spaceweather-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server