NOAA SWPC space weather: storm scales, Kp index, aurora forecasts, solar wind, activity, alerts.
Active SWPC alerts, watches, and warnings — parsed into structured records with product type, NOAA scale and level, issue time, validity window, and plain text. Covers geomagnetic storms, radio blackouts, and radiation storms. With active_only=false, also returns informational summaries, expired notices, and cancellations. max_age_hours controls how far back to look (default 48 h); the SWPC feed keeps all historical records and has no built-in expiry.
| Name | Required | Description | Default |
|---|---|---|---|
| active_only | No | When true (default), return only in-force Warnings, Watches, and Alerts; exclude Summaries, Other, expired products, and cancellation notices. Set false to return all products, including cancellations (flagged by the cancelled field). | |
| max_age_hours | No | Maximum age of alerts to return, in hours (default 48). The SWPC feed retains all historical records — this window prevents returning weeks of historical notices as "active." |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| alerts | No | Matching SWPC alert/watch/warning records. |
| notice | No | Status notice when no alerts are active. |
| fetchedAt | No | ISO 8601 timestamp of when this data was fetched. |
| totalCount | No | Count of records in the alerts array. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it explains that the SWPC feed retains all historical records with no built-in expiry, and that max_age_hours controls the lookback window, which could surprise users expecting default feed expiration. It also specifies the effect of active_only=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight paragraph of three sentences. It is front-loaded with the core purpose, then adds parameter behavior without any filler or repetition of schema information. Every sentence contributes a distinct piece of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 but implied by 'has output schema: true'), the description does not need to enumerate return fields. It covers parameter defaults, edge cases (historical retention, inclusion of expired notices), and the tool's scope. There are no missing details that would prevent correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters already have detailed schema descriptions covering defaults and filtering behavior, so the baseline is 3. The description adds extra meaning by noting that the feed keeps all historical records and that max_age_hours prevents returning weeks of historical notices as 'active'—a nuance not present in the schema, which only states a maximum and minimum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: returns active SWPC alerts, watches, and warnings, parsed into structured records with explicit fields (product type, NOAA scale, issue time, validity window, plain text). It also names the three storm types covered (geomagnetic storms, radio blackouts, radiation storms), which distinguishes it from sibling tools like aurora forecast or solar wind.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on what the tool returns and how it behaves with active_only=false, and explains the max_age_hours parameter. However, it does not explicitly name any sibling tools or state when not to use this tool, so there are no explicit exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OVATION model aurora forecast for the next ~30–60 min: global grid of aurora probability percentages by latitude/longitude (1° resolution). With optional coordinates, returns the local aurora probability at the nearest grid point, the minimum Kp needed for aurora at that latitude, and a plain-language go/no-go verdict. Without coordinates, returns only global metadata. Data updates every ~5 minutes. Coordinates are geographic (WGS84), not geomagnetic.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | No | Geographic latitude in degrees (−90 to 90). Provide with longitude for a local aurora probability lookup. | |
| longitude | No | Geographic longitude in degrees (−180 to 180). Provide with latitude for a local aurora probability lookup. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| localLookup | No | Local aurora lookup result. Null when no coordinates were provided. |
| forecastTime | No | Time the aurora forecast is valid for, ISO 8601. |
| gridPointCount | No | Total number of grid points in the OVATION model. |
| observationTime | No | Time of the OVATION model observation, ISO 8601. |
| topAuroraRegion | No | Approximate region of the highest aurora probability grid point. |
| topAuroraPercent | No | Highest aurora probability anywhere on the globe (0–100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses rich behavioral traits beyond the annotations: data update frequency (~5 minutes), coordinate system (WGS84 geographic, not geomagnetic), and the conditional return behavior (local probability, Kp needed, go/no-go verdict with coordinates; global metadata without). These details are not present in the annotations (readOnly, openWorld, idempotent) and significantly aid correct invocation and interpretation. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences with no redundancy. It front-loads the core function in the first sentence, then methodically explains parameter modes, update frequency, and coordinate system. Every sentence earns its place, and the structure is easy to parse for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a tool of this complexity: it covers the data model, parameter behavior, output types, update frequency, and coordinate nuance. The output schema exists (as indicated), so return structure is handled elsewhere. Nothing an agent needs to call the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for latitude and longitude (ranges, degrees). The description adds essential semantics beyond the schema: that coordinates are geographic (WGS84) not geomagnetic, and that providing both together triggers local lookup while omitting them returns global metadata. This complementary meaning raises the score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (get), resource (OVATION model aurora forecast), and detailed scope: a global grid of aurora probability percentages at 1° resolution for the next 30–60 minutes. It clearly distinguishes from sibling tools (alerts, conditions, kp index, solar activity, solar wind) by naming the exact phenomenon and data. The two operational modes (with/without coordinates) further clarify the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when an aurora forecast is needed, and the parameter modes (with coordinates for local probability, without for global metadata) are explicitly described. However, it does not explicitly name alternatives or state when not to use this tool versus siblings, though the purpose is so specific that an agent can infer the correct selection. The absence of explicit exclusions prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current space-weather snapshot: NOAA R/S/G storm scales (today + 3-day forecast), latest Kp index with its G-scale equivalent and aurora-visibility latitude, and a plain-language status summary. The quickest way to answer "is anything happening right now?" — use before deciding whether to drill into solar wind (noaa_spaceweather_get_solar_wind), aurora (noaa_spaceweather_get_aurora_forecast), or alert details (noaa_spaceweather_get_alerts).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| today | No | Current observed NOAA storm scales for today. |
| summary | No | Plain-language status summary suitable for display, e.g. "Quiet conditions" or "G2 moderate geomagnetic storm in progress." |
| forecast | No | 3-day NOAA scale forecast (next 1–3 days). |
| currentKp | No | Latest observed planetary K-index (0–9). |
| observedAt | No | UTC date and time of the NOAA scales data period this snapshot reflects, e.g. "2026-06-04 15:00:00". |
| currentGScale | No | NOAA G-scale equivalent for current Kp (0–5). |
| auroraLatitude | No | Aurora visibility guidance for current conditions, e.g. "Aurora possible to ~55° geomagnetic latitude". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds value by specifying the data contents (storm scales, Kp, plain-language summary) and describing it as a 'snapshot,' which implies current-state retrieval rather than a long operation. No contradictions; the added content is meaningful context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core content, and the second provides routing guidance. Every sentence earns its place—no filler. It's an efficient, well-structured definition that a model can parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with an output schema, the description fully covers what the tool does, what it returns, and when to use it. The output schema handles return details, and annotations cover safety. Nothing an agent needs to call this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema shows no properties. The description doesn't need to explain parameter semantics because there are none. Per the guidelines, 0 params gives a baseline of 4, which is appropriate here. The description clearly explains what the tool returns, so the agent knows what to expect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('space weather conditions') and enumerates the exact content: NOAA R/S/G storm scales, Kp index with G-scale equivalent and aurora-visibility latitude, and a plain-language status summary. It explicitly differentiates from siblings by framing itself as the quickest snapshot, which distinguishes it from the more specialized solar wind, aurora, and alert tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'The quickest way to answer "is anything happening right now?" — use before deciding whether to drill into solar wind, aurora, or alert details.' It names the alternatives and the decision point, leaving no ambiguity about when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Planetary K-index (0–9 geomagnetic activity scale) — recent observed 3-hour values with their NOAA G-scale equivalents and aurora-latitude guidance, plus the 3-day Kp forecast series. Kp is the primary driver of aurora visibility and geomagnetic storm severity: Kp≥5 is G1, Kp≥7 is G3 (aurora to ~50°), Kp≥9 is G5 extreme. Use noaa_spaceweather_get_conditions for a combined snapshot including storm scales; use this tool when you need the Kp time series or forecast detail.
| Name | Required | Description | Default |
|---|---|---|---|
| window_days | No | Number of past days of observed Kp to return (1–7, default 1). Larger windows show trend context. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| forecast | No | Forward-looking Kp forecast series (estimated and predicted entries only; observed history excluded). |
| observed | No | Observed Kp readings within the requested window, oldest first. |
| currentKp | No | Latest observed Kp value. |
| currentGScale | No | NOAA G-scale for current Kp. |
| observedCount | No | Number of Kp observations in the observed array, matching the requested window. |
| auroraLatitude | No | Aurora visibility guidance for current conditions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds valuable behavioral context: it specifies the output includes observed values and forecast series, and provides a Kp-to-G-scale and aurora-latitude mapping to help interpret results. It does not cover rate limits or auth, but with annotations covering safety, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, the first front-loads the core function and output. The second sentence explains the Kp scale thresholds and aurora correlations, which is informative but arguably background knowledge. The third sentence provides routing to an alternative. Each sentence earns its place, though the scale explanation could be considered slightly tangential. Overall well-structured and not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and an existing output schema, the description is complete. It covers what is returned (observed and forecast series), how to interpret it (G-scale mapping, aurora latitude), and when to use it vs an alternative. The output schema documents the exact structure, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single parameter window_days has a full description in the schema, including range and purpose. The tool description does not mention the parameter at all, which is acceptable given the high schema coverage. The baseline of 3 applies, and the description adds no additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns recent observed 3-hour Kp values with NOAA G-scale equivalents and aurora-latitude guidance, plus a 3-day forecast series. It also explains the Kp index scale and its significance, and explicitly differentiates from the sibling tool noaa_spaceweather_get_conditions by stating which tool to use for a combined snapshot. The verb+resource is 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names the alternative tool (noaa_spaceweather_get_conditions) and provides a clear selection criterion: use the conditions tool for a combined snapshot including storm scales, and this tool when Kp time series or forecast detail is needed. This gives explicit when-to-use and when-not-to-use guidance, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solar flare and radiation storm picture: recent GOES X-ray flux with flare-class labels (A/B/C/M/X), 3-day flare-class probabilities (C/M/X), active solar regions with per-region flare probabilities, and GOES integral proton flux at ≥10 MeV with NOAA S-scale. For operators tracking HF radio blackout (R-scale, driven by X-ray) and radiation storm risk (S-scale, driven by protons). Active region data helps identify which region is driving current activity.
| Name | Required | Description | Default |
|---|---|---|---|
| include_regions | No | Include active solar region details (default true). Set false to skip region data and reduce response size. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| sScale | No | Current NOAA S-scale for solar radiation storms (0–5), derived from latest proton flux. |
| fetchedAt | No | ISO 8601 timestamp of when this data was fetched. |
| latestXray | No | Most recent GOES X-ray flux reading, null if unavailable. |
| recentXray | No | GOES X-ray flux readings from the past hour, oldest first. |
| sScaleText | No | Plain-language S-scale description, e.g. "S2 moderate radiation storm". |
| latestProton | No | Most recent ≥10 MeV proton flux reading, null if unavailable. |
| activeRegions | No | Currently active solar regions with per-region flare probabilities. Empty when include_regions=false or no regions are active. |
| probabilities | No | 3-day flare probability forecasts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, so the description does not need to restate safety. It adds value by describing the data composition and explaining that 'Active region data helps identify which region is driving current activity,' giving behavioral context beyond the annotation metadata. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core concept ('Solar flare and radiation storm picture:'), then enumerates specific data points and finishes with the operational significance. There is no redundancy; every sentence contributes to understanding the tool's functionality and relevance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is read-only with one optional parameter and an output schema present, the description effectively covers what data is returned, the purpose, and the use case. It explains the meaning of the data (R-scale, S-scale, active regions) sufficiently for an agent to decide when to invoke it. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, documenting the include_regions parameter with its default and purpose. The description mentions active region data but does not directly explain the parameter, so it adds minimal extra meaning beyond what the schema already provides. Baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'Solar flare and radiation storm picture' with specific data elements (GOES X-ray flux, flare-class probabilities, active regions, proton flux). It identifies the resource and content uniquely, but does not explicitly distinguish it from sibling tools like get_alerts or get_conditions, though the described data is clearly distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context for when to use it: 'For operators tracking HF radio blackout (R-scale, driven by X-ray) and radiation storm risk (S-scale, driven by protons).' This clarifies the intended use case and target audience, though it does not mention alternatives or when not to use other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Real-time solar wind measurements from the active spacecraft at L1: proton speed (km/s), density (n/cm³), temperature (K), and the critical Bz component (southward Bz = negative = storm driver). Returns the recent plasma and magnetic field time series within the requested window, oldest first, each record tagged with the reporting spacecraft. Bz < −10 nT for sustained periods is a primary geomagnetic storm trigger — use alongside noaa_spaceweather_get_kp_index to see whether elevated solar wind has translated into a geomagnetic storm.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No | Hours of recent solar wind history to return (1–168, default 3). Records update ~every 1 min, but the feed only carries roughly the last 24 hours — a larger window returns the whole feed, not more history. When a window comes back empty, feedStalenessHours and latestFeedPlasmaTime/latestFeedMagTime report how current the feed actually is. |
| Name | Required | Description |
|---|---|---|
| mag | No | Magnetic field measurements (Bx, By, Bz, Bt) within the window, oldest first. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when the requested window returned no plasma or magnetic field records — names the newest record the feed carries, or reports that the feed itself returned nothing from an active spacecraft. |
| plasma | No | Plasma measurements (speed, density, temperature) within the window, oldest first. |
| bzStatus | No | Plain-language Bz status, e.g. "Southward Bz −14 nT — storm-driving conditions" or "Northward Bz +5 nT — quiescent". |
| magCount | No | Number of magnetic field records in the mag array, spanning the requested window. |
| latestMag | No | Most recent magnetic field reading, null if no data in window. |
| plasmaCount | No | Number of plasma records in the plasma array, spanning the requested window. |
| latestPlasma | No | Most recent plasma reading, null if no data in window. |
| latestFeedMagTime | No | ISO 8601 time of the newest magnetic field record the feed carries, ignoring the window. Null when the feed returned no active-spacecraft mag records. |
| feedStalenessHours | No | Hours between now and the newest record across both feeds — how far behind real time the upstream data is. Null when both feeds returned no active-spacecraft records. |
| latestFeedPlasmaTime | No | ISO 8601 time of the newest plasma record the feed carries, ignoring the window. Null when the feed returned no active-spacecraft plasma records. Compare against the window to tell a quiet feed from a stale one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent, but the description adds substantial behavior beyond that: update frequency (~1 min), feed retention (~24 hours), that larger windows return the whole feed, records sorted oldest-first, spacecraft tagging, and handling of empty windows via feedStalenessHours/latestFeed times. This covers edge cases and data provenance thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While lengthy, every sentence adds operational value—data content, sorting, spacecraft tags, storm significance, and cross-referencing. The main purpose is front-loaded, and the structure flows from what the tool returns to how to interpret it. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (feed special cases, storm relevance), the description is complete: it covers the data, the parameter's behavior, what to pair it with, and how to interpret errors (empty window). The output schema exists, so return details aren't needed. The description fully enables correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes window_hours with range and default (100% coverage, baseline 3), but the description adds critical semantics: what happens with windows >24h (returns whole feed, not more history), the meaning of an empty window, and how to check feed currentness. This goes beyond the schema and directly impacts correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Real-time solar wind measurements from the active spacecraft at L1', and enumerates exact data fields (proton speed, density, temperature, Bz). It clearly distinguishes itself from sibling tools (alerts, aurora, conditions, KP, solar activity) by focusing on solar wind plasma and magnetic field data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: Bz threshold for storm triggers, and explicitly recommends using alongside noaa_spaceweather_get_kp_index to assess storm translation. While it doesn't explicitly state 'don't use for X', the domain is so specific that alternatives are obvious, and the pairing guidance is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
NOAA Space Weather Prediction Center (solar wind, Kp, aurora, alerts)
Space weather: Kp index, NOAA 3-day geomagnetic forecast, solar flares, aurora visibility.
Space weather: Kp index, solar flare flux, alerts. $0.01/query, free testnet funds.
NOAA Storm Prediction Center — outlooks, storm reports, watches
Add one secure layer between your agents and this server.
Each tool targets a distinct aspect of space weather: alerts, aurora forecast, conditions snapshot, Kp index, solar activity, and solar wind. No two tools serve the same purpose, and the descriptions clearly delineate when to use each (e.g., conditions for a quick overview versus Kp for time series detail).
All tools follow the exact same pattern: `noaa_spaceweather_get_<resource>`. This is perfectly consistent and predictable, making it easy for an agent to infer tool purpose from the name alone.
With 6 tools, the server covers the major space-weather data categories without being overwhelming. Each tool provides substantial, non-redundant information, and the scope aligns well with what an agent might need for operational space-weather queries.
The tool set spans alerts/warnings, current conditions, KP index, solar activity, solar wind, and aurora forecasts – covering the full lifecycle of space-weather monitoring. No obvious missing operations exist; the description even cross-references tools to guide exploration (e.g., conditions leads to solar wind, aurora, or alerts).
